Compliance of RFC 7427 - Signature Authentication in IKEv2: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
No edit summary
Line 16: Line 16:


1.  Hash Algorithm Notification
1.  Hash Algorithm Notification
Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent inside the IKE_SA_INIT exchange.
Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent inside the IKE_SA_INIT exchange.
The supported hash algorithms like SHA1, SHA2 and IDENTITY are exchanged by the initiator and responder in this notify. The negotiated hash algorithm is the one that is supported by both the parties. This hash algorithm is further used to generate the signature sent in the Authentication payload.
The supported hash algorithms like SHA1, SHA2 and IDENTITY are exchanged by the initiator and responder in this notify. The negotiated hash algorithm is the one that is supported by both the parties. This hash algorithm is further used to generate the signature sent in the Authentication payload.


2. Authentication payload
2. Authentication payload
A new authentication method called Digital Signature which is sent in the IKE_AUTH message exchange. Earlier, the Authentication Data field inside the Authentication payload contained only the signature value. Now, signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used while calculating the signature. [https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 IANA registry] specifies the values to be used. On Libreswan, the Digital Signature Authentication method only includes support for RSA with SHA-1.
A new authentication method called Digital Signature which is sent in the IKE_AUTH message exchange. Earlier, the Authentication Data field inside the Authentication payload contained only the signature value. Now, signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used while calculating the signature. [https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 IANA registry] specifies the values to be used. On Libreswan, the Digital Signature Authentication method only includes support for RSA with SHA-1.


3. Testing framework
3. Testing framework
Test Suite was extended by adding test cases to verify feature functionality and perform interoperability tests. Negative tests cases were added using impairments that emulate clients that do not support the Digital Signature Authentication scheme as specified by the RFC 7427
Test Suite was extended by adding test cases to verify feature functionality and perform interoperability tests. Negative tests cases were added using impairments that emulate clients that do not support the Digital Signature Authentication scheme as specified by the RFC 7427



Revision as of 22:30, 28 August 2017

Introduction

Currently in the Internet Key Exchange version 2 (IKEv2), signature based authentication is per algorithm i.e., there is one for RSA digital signatures, one for DSS digital signatures (using SHA-1), and three for different ECDSA curves, each tied to exactly one hash algorithm. This leads to 2 problems:

  • The sending and receiving parties do not know which Hash algorithm is used to generate a signature.
  • Each time there is a new Signature algorithm, a new Authentication method is required.

Therefore this design is cumbersome when more signature algorithms, hash algorithms, and elliptic curves need to be supported.

RFC 7427 solves these problems by generalising the IKEv2 signature support to allow any signature method supported by PKIX and also adds a signature hash algorithm negotiation. RFC 7427 recommends a new digital signature method. This method is flexible to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add new methods (ECGDSA, ElGamal, etc.) in the future.

Implementation

To make Libreswan RFC 7427 compliant, the following items are implemented :

1. Hash Algorithm Notification

Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent inside the IKE_SA_INIT exchange. The supported hash algorithms like SHA1, SHA2 and IDENTITY are exchanged by the initiator and responder in this notify. The negotiated hash algorithm is the one that is supported by both the parties. This hash algorithm is further used to generate the signature sent in the Authentication payload.

2. Authentication payload

A new authentication method called Digital Signature which is sent in the IKE_AUTH message exchange. Earlier, the Authentication Data field inside the Authentication payload contained only the signature value. Now, signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used while calculating the signature. IANA registry specifies the values to be used. On Libreswan, the Digital Signature Authentication method only includes support for RSA with SHA-1.

3. Testing framework

Test Suite was extended by adding test cases to verify feature functionality and perform interoperability tests. Negative tests cases were added using impairments that emulate clients that do not support the Digital Signature Authentication scheme as specified by the RFC 7427


Issues encountered

Future work

  • Currently Libreswan only supports RSA as the digital signature authentication method. It has to be enhanced to support other Public encryption/Signature algorithms such as DSA, ECDSA, RSASSA-PSS.
  • RSA version needs to be updated from v1.5 to PSS.
  • Support for Hash Algorithm SHA-2.

source code

Feature implementation

Addition and modification of test cases

This project work was sponsored by Google as part of the Google Summer of Code 2017 Program. The implementation for this project is done by Sahana Prasad (sahana.prasad07@gmail.com) under the tutelage of Paul Wouters.