doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7427.txt b/doc/rfc/rfc7427.txt
new file mode 100644
index 0000000..d8ecb5b
--- /dev/null
+++ b/doc/rfc/rfc7427.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Kivinen
+Request for Comments: 7427                                 INSIDE Secure
+Updates: 7296                                                  J. Snyder
+Category: Standards Track                                       Opus One
+ISSN: 2070-1721                                             January 2015
+
+
+Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
+
+Abstract
+
+   The Internet Key Exchange Version 2 (IKEv2) protocol has limited
+   support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
+   The current version only includes support for three Elliptic Curve
+   groups, and there is a fixed hash algorithm tied to each group.  This
+   document generalizes IKEv2 signature support to allow any signature
+   method supported by PKIX and also adds signature hash algorithm
+   negotiation.  This is a generic mechanism and is not limited to
+   ECDSA; it can also be used with other signature algorithms.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7427.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 1]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Authentication Payload  . . . . . . . . . . . . . . . . . . .   4
+   4.  Hash Algorithm Notification . . . . . . . . . . . . . . . . .   6
+   5.  Selecting the Public Key Algorithm  . . . . . . . . . . . . .   7
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+   Appendix A.  Commonly Used ASN.1 Objects  . . . . . . . . . . . .  12
+     A.1.  PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . .  12
+       A.1.1.  sha1WithRSAEncryption . . . . . . . . . . . . . . . .  12
+       A.1.2.  sha256WithRSAEncryption . . . . . . . . . . . . . . .  12
+       A.1.3.  sha384WithRSAEncryption . . . . . . . . . . . . . . .  13
+       A.1.4.  sha512WithRSAEncryption . . . . . . . . . . . . . . .  13
+     A.2.  DSA . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
+       A.2.1.  dsa-with-sha1 . . . . . . . . . . . . . . . . . . . .  13
+       A.2.2.  dsa-with-sha256 . . . . . . . . . . . . . . . . . . .  14
+     A.3.  ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . .  14
+       A.3.1.  ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . .  14
+       A.3.2.  ecdsa-with-sha256 . . . . . . . . . . . . . . . . . .  14
+       A.3.3.  ecdsa-with-sha384 . . . . . . . . . . . . . . . . . .  15
+       A.3.4.  ecdsa-with-sha512 . . . . . . . . . . . . . . . . . .  15
+     A.4.  RSASSA-PSS  . . . . . . . . . . . . . . . . . . . . . . .  15
+       A.4.1.  RSASSA-PSS with Empty Parameters  . . . . . . . . . .  15
+       A.4.2.  RSASSA-PSS with Default Parameters  . . . . . . . . .  16
+       A.4.3.  RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . .  17
+   Appendix B.  IKEv2 Payload Example  . . . . . . . . . . . . . . .  17
+     B.1.  sha1WithRSAEncryption . . . . . . . . . . . . . . . . . .  17
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+1.  Introduction
+
+   This document adds a new IKEv2 [RFC7296] authentication method to
+   support signature methods in a more general way.  The current
+   signature-based authentication methods in IKEv2 are 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 design is cumbersome when
+   more signature algorithms, hash algorithms, and elliptic curves need
+   to be supported:
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 2]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   o  In IKEv2, authentication using RSA digital signatures calls for
+      padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS
+      padding method is now recommended.  (See Section 5 of "Additional
+      Algorithms and Identifiers for RSA Cryptography for use in PKIX
+      Profile" [RFC4055].)
+
+   o  With ECDSA and the Digital Signature Standard (DSS), there is no
+      way to extract the hash algorithm from the signature.  Thus, for
+      each new hash function to be supported with ECDSA or DSA, new
+      authentication methods would be needed.  Support for new hash
+      functions is particularly needed for DSS, because the current
+      restriction to SHA-1 limits its security, meaning there is no
+      point of using long keys with SHA-1.
+
+   o  The tying of ECDSA authentication methods to particular elliptic
+      curve groups requires definition of additional methods for each
+      new group.  The combination of new ECDSA groups and hash functions
+      will cause the number of required authentication methods to become
+      unmanageable.  Furthermore, the restriction of ECDSA
+      authentication to a specific group is inconsistent with the
+      approach taken with DSS.
+
+   With the selection of SHA-3, it might be possible that a signature
+   method can be used with either SHA-3 or SHA-2.  This means that a new
+   mechanism for negotiating the hash algorithm for a signature
+   algorithm is needed.
+
+   This document specifies two things:
+
+   1.  A new authentication method that includes enough information
+       inside the Authentication payload data so the signature hash
+       algorithm can be extracted (see Section 3).
+
+   2.  A method to indicate supported signature hash algorithms (see
+       Section 4).  This allows the peer to know which hash algorithms
+       are supported by the other end and use one of them (provided one
+       is allowed by policy).  There is no requirement to actually
+       negotiate one common hash algorithm, as different hash algorithms
+       can be used in different directions if needed.
+
+   The new digital signature method is flexible enough to include all
+   current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add
+   new methods (ECGDSA, ElGamal, etc.) in the future.  To support this
+   flexibility, the signature algorithm is specified in the same way
+   that PKIX [RFC5280] specifies the signature of the Digital
+   Certificate, by placing a simple ASN.1 object before the actual
+   signature data.  This ASN.1 object contains an OID specifying the
+   algorithm and associated parameters.  When an IKEv2 implementation
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 3]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   supports a fixed set of signature methods with commonly used
+   parameters, it is acceptable for the implementation to treat the
+   ASN.1 object as a binary blob that can be compared against the fixed
+   set of known values.  IKEv2 implementations can also parse the ASN.1
+   and extract the signature algorithm and associated parameters.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Authentication Payload
+
+   This document specifies a new "Digital Signature" authentication
+   method.  This method can be used with any type of signature.  As the
+   authentication methods are not negotiated in IKEv2, the peer is only
+   allowed to use this authentication method if the Notify payload of
+   type SIGNATURE_HASH_ALGORITHMS has been sent and received by each
+   peer.
+
+   In this authentication method, the Authentication Data field inside
+   the Authentication payload does not just include the signature value,
+   as do other existing IKEv2 Authentication payloads.  Instead, the
+   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 when calculating the signature.  In
+   addition to the OID, the ASN.1 object can contain optional parameters
+   that might be needed for algorithms such as RSASSA-PSS (see
+   Section 8.1 of [RFC3447]).
+
+   To make implementations easier, the ASN.1 object is prefixed by the
+   8-bit length field.  This length field allows simple implementations
+   to know the length of the ASN.1 object without the need to parse it,
+   so they can use it as a binary blob to be compared against known
+   signature algorithm ASN.1 objects.  Thus, simple implementations may
+   not need to be able to parse or generate ASN.1 objects.  See
+   Appendix A for commonly used ASN.1 objects.
+
+   The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier
+   of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using
+   distinguished encoding rules (DER) [CCITT.X690.2002].  The algorithm
+   OID inside the ASN.1 specifies the signature algorithm and the hash
+   function, both of which are needed for signature verification.
+
+   Currently, only the RSASSA-PSS signature algorithm uses the optional
+   parameters.  For other signature algorithms, the parameters are
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 4]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   either NULL or missing.  Note that for some algorithms there are two
+   possible ASN.1 encodings, one with optional parameters included but
+   set to NULL and the other where the optional parameters are omitted.
+   These dual encodings exist because of the way those algorithms are
+   specified.  When encoding the ASN.1, implementations SHOULD use the
+   preferred format called for by the algorithm specification.  If the
+   algorithm specification says "preferredPresent", then the parameters
+   object needs to be present, although it will be NULL if no parameters
+   are specified.  If the algorithm specification says
+   "preferredAbsent", then the entire optional parameters object is
+   missing.
+
+   The Authentication payload is defined in IKEv2 as follows:
+
+                           1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Next Payload  |C|  RESERVED   |         Payload Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Auth Method   |                RESERVED                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                      Authentication Data                      ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 1: Authentication Payload Format
+
+   o  Auth Method (1 octet) - Specifies the method of authentication
+      used.
+
+      Mechanism                              Value
+      -----------------------------------------------------------------
+      Digital Signature                      14
+
+      Computed as specified in Section 2.15 of [RFC7296] using a private
+      key associated with the public key sent in the Certificate payload
+      and using one of the hash algorithms sent by the other end in the
+      Notify payload of type SIGNATURE_HASH_ALGORITHMS.  If both ends
+      send and receive SIGNATURE_HASH_ALGORITHMS Notify payloads, and
+      signature authentication is to be used, then the authentication
+      method specified in this Authentication payload MUST be used.  The
+      format of the Authentication Data field is different from other
+      Authentication methods and is specified below.
+
+   o  Authentication Data (variable length) - See Section 2.15 of
+      [RFC7296].  For "Digital Signature" format, the Authentication
+      Data is formatted as follows:
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 5]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+                           1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | ASN.1 Length  | AlgorithmIdentifier ASN.1 object              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~        AlgorithmIdentifier ASN.1 object continuing            ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                         Signature Value                       ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 2: Authentication Data Format
+
+      *  ASN.1 Length (1 octet) - This field contains the length of the
+         ASN.1-encoded AlgorithmIdentifier object.
+
+      *  Algorithm Identifier (variable length) - This field contains
+         the AlgorithmIdentifier ASN.1 object.
+
+      *  Signature Value (variable length) - This field contains the
+         actual signature value.
+
+      There is no padding between the ASN.1 object and the signature
+      value.  For hash truncation, the method specified in ANSI
+      X9.62:2005 [X9.62] MUST be used.
+
+4.  Hash Algorithm Notification
+
+   The supported hash algorithms that can be used for the signature
+   algorithms are indicated with a Notify payload of type
+   SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
+
+   This notification also implicitly indicates support of the new
+   "Digital Signature" algorithm method, as well as the list of hash
+   functions supported by the sending peer.
+
+   Both ends send their list of supported hash algorithms.  When
+   calculating the digital signature, a peer MUST pick one algorithm
+   sent by the other peer.  Note that different algorithms can be used
+   in different directions.  The algorithm OID indicating the selected
+   hash algorithm (and signature algorithm) used when calculating the
+   signature is sent inside the Authentication Data field of the
+   Authentication payload (with Auth Method of "Digital Signature" as
+   defined above).
+
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 6]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+                           1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Next Payload  |C|  RESERVED   |         Payload Length        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Protocol ID  |   SPI Size    |      Notify Message Type      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                Security Parameter Index (SPI)                 ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       Notification Data                       ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 3: Notify Payload Format
+
+   The Notify payload format is defined in Section 3.10 of [RFC7296].
+   When a Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the
+   Protocol ID field is set to 0, the SPI Size is set to 0, and the
+   Notify Message Type is set to 16431.
+
+   The Notification Data field contains the list of 16-bit hash
+   algorithm identifiers from the Hash Algorithm Identifiers of IANA's
+   "Internet Key Exchange Version 2 (IKEv2) Parameters" registry.  There
+   is no padding between the hash algorithm identifiers.
+
+5.  Selecting the Public Key Algorithm
+
+   This specification does not provide a way for the peers to indicate
+   the public/private key pair types they have.  This raises the
+   question of how the responder selects a public/private key pair type
+   that the initiator supports.  This information can be found by
+   several methods.
+
+   One method to signal the key the initiator wants the responder to use
+   is to indicate that in the IDr (Identification - Responder) payload
+   of the IKE_AUTH request sent by the initiator.  In this case, the
+   initiator indicates that it wants the responder to use a particular
+   public/private key pair by sending an IDr payload that indicates that
+   information.  In this case, the responder has different identities
+   configured, with each of those identities associated to a public/
+   private key or key type.
+
+   Another method to ascertain the key the initiator wants the responder
+   to use is through a Certificate Request payload sent by the
+   initiator.  For example, the initiator could indicate in the
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 7]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   Certificate Request payload that it trusts a certificate authority
+   certificate signed by an ECDSA key.  This indication implies that the
+   initiator can process ECDSA signatures, which means that the
+   responder can safely use ECDSA keys when authenticating.
+
+   A third method is for the responder to check the key type used by the
+   initiator and use the same key type that the initiator used.  This
+   method does not work if the initiator is using shared secret or
+   Extensible Authentication Protocol (EAP) authentication (i.e., is not
+   using public keys).  If the initiator is using public key
+   authentication, this method is the best way for the responder to
+   ascertain the type of key the initiator supports.
+
+   If the initiator uses a public key type that the responder does not
+   support, the responder replies with a Notify message with error type
+   AUTHENTICATION_FAILED.  If the initiator has multiple different keys,
+   it may try a different key (and perhaps a different key type) until
+   it finds a key that the other end accepts.  The initiator can also
+   use the Certificate Request payload sent by the responder to help
+   decide which public key should be tried.  In normal cases, when the
+   initiator has multiple public keys, out-of-band configuration is used
+   to select a public key for each connection.
+
+6.  Security Considerations
+
+   Tables 2 and 3 of the "Recommendations for Key Management"
+   [NIST800-57] give recommendations for how to select suitable hash
+   functions for the signature.
+
+   This new digital signature method does not tie the Elliptic Curve to
+   a specific hash function, which was done in the old IKEv2 ECDSA
+   methods.  This means it is possible to mix different security levels.
+   For example, it is possible to use a 512-bit Elliptic Curve with
+   SHA1.  This means that the security of the authentication method is
+   the security of the weakest component (signature algorithm, hash
+   algorithm, or curve).  This complicates the security analysis of the
+   system.
+
+   IKEv2 peers have a series of policy databases (see Section 4.4 of
+   [RFC4301]) that define which security algorithms and methods should
+   be used during establishment of security associations.  To help end
+   users select the desired security levels for communications protected
+   by IPsec, implementers may wish to provide a mechanism in the IKE
+   policy databases to limit the mixing of security levels or to
+   restrict combinations of protocols.
+
+   Security downgrade attacks, where more secure methods are deleted or
+   modified from a payload by a man-in-the-middle to force lower levels
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 8]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   of security, are not a significant concern in IKEv2 Authentication
+   payloads, as discussed in this RFC.  This is because a modified AUTH
+   payload will be detected when the peer computes a signature over the
+   IKE messages.
+
+   One specific class of downgrade attacks requires selection of
+   catastrophically weak ciphers.  In this type of attack, the man-in-
+   the-middle attacker is able to "break" the cryptography in real time.
+   This type of downgrade attack should be blocked by policy regarding
+   cipher algorithm selection, as discussed above.
+
+   The hash algorithm registry does not include MD5 as a supported hash
+   algorithm, as it is not considered safe enough for signature use
+   [WY05].
+
+   The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known
+   security vulnerabilities [KA08] [ME01] and does not allow using newer
+   padding methods such as RSASSA-PSS.  The new method described in this
+   RFC allows the use of other padding methods.
+
+   The current IKEv2 protocol only allows use of normal DSA with SHA-1,
+   which means the security of the authentication is limited to the
+   security of SHA-1.  This new method allows using longer keys and
+   longer hashes with DSA.
+
+7.  IANA Considerations
+
+   This document creates a new IANA registry for IKEv2 Hash Algorithms.
+   Changes and additions to this registry are by Expert Review
+   [RFC5226].
+
+   The initial values of this registry are:
+
+   Hash Algorithm                       Value
+   --------------                       -----
+   RESERVED                             0
+   SHA1                                 1
+   SHA2-256                             2
+   SHA2-384                             3
+   SHA2-512                             4
+
+   MD5 is not included in the hash algorithm list, as it is not
+   considered safe enough for signature hash uses.
+
+   Values 5-1023 are Unassigned.  Values 1024-65535 are reserved for
+   Private Use among mutually consenting parties.
+
+
+
+
+
+Kivinen & Snyder             Standards Track                    [Page 9]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   This specification also adds a new value for
+   SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types
+   - Status Types" registry and adds a new value for Digital Signature
+   (14) to the "IKEv2 Authentication Method" registry.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008,
+              <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+              Kivinen, "Internet Key Exchange Protocol Version 2
+              (IKEv2)", RFC 7296, October 2014,
+              <http://www.rfc-editor.org/info/rfc7296>.
+
+8.2.  Informative References
+
+   [CCITT.X690.2002]
+              International Telephone and Telegraph Consultative
+              Committee, "ASN.1 encoding rules: Specification of basic
+              encoding Rules (BER), Canonical encoding rules (CER) and
+              Distinguished encoding rules (DER)", CCITT Recommendation
+              X.690, July 2002.
+
+   [KA08]     Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
+              "Variants of Bleichenbacher's Low-Exponent Attack on
+              PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008,
+              pp.97-109, 2008.
+
+   [ME01]     Menezes, A., "Evaluation of Security Level of
+              Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December
+              2001.
+
+   [NIST800-57]
+              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
+              "Recommendation for Key Management - Part 1: General
+              (Revised)", NIST Special Publication 800-57, March 2007.
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 10]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
+              Identifiers for the Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 3279, April 2002,
+              <http://www.rfc-editor.org/info/rfc3279>.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003,
+              <http://www.rfc-editor.org/info/rfc3447>.
+
+   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
+              Algorithms and Identifiers for RSA Cryptography for use in
+              the Internet X.509 Public Key Infrastructure Certificate
+              and Certificate Revocation List (CRL) Profile", RFC 4055,
+              June 2005, <http://www.rfc-editor.org/info/rfc4055>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005,
+              <http://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs)", BCP 26, RFC 5226,
+              May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+              "Elliptic Curve Cryptography Subject Public Key
+              Information", RFC 5480, March 2009,
+              <http://www.rfc-editor.org/info/rfc5480>.
+
+   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
+              Polk, "Internet X.509 Public Key Infrastructure:
+              Additional Algorithms and Identifiers for DSA and ECDSA",
+              RFC 5758, January 2010,
+              <http://www.rfc-editor.org/info/rfc5758>.
+
+   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
+              June 2010, <http://www.rfc-editor.org/info/rfc5912>.
+
+   [WY05]     Wang, X. and H. Yu, "How to break MD5 and other hash
+              functions", Proceedings of EuroCrypt 2005, Lecture Notes
+              in Computer Science Vol. 3494, 2005.
+
+   [X9.62]    American National Standards Institute, "Public Key
+              Cryptography for the Financial Services Industry: The
+              Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
+              X9.62, November 2005.
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 11]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+Appendix A.  Commonly Used ASN.1 Objects
+
+   This section lists commonly used ASN.1 objects in binary form.  This
+   section is not normative, and these values should only be used as
+   examples.  If the ASN.1 object listed in Appendix A and the ASN.1
+   object specified by the algorithm differ, then the algorithm
+   specification must be used.  These values are taken from "New ASN.1
+   Modules for the Public Key Infrastructure Using X.509 (PKIX)"
+   [RFC5912].
+
+A.1.  PKCS#1 1.5 RSA Encryption
+
+   The algorithm identifiers here include several different ASN.1
+   objects with different hash algorithms.  This document only includes
+   the commonly used ones, i.e., the ones using SHA-1 or SHA-2 as the
+   hash function.  Some other algorithms (such as MD2 and MD5) are not
+   safe enough to be used as signature hash algorithms and are omitted.
+   The IANA registry does not have code points for these other
+   algorithms with RSA Encryption.  Note that there are no optional
+   parameters in any of these algorithm identifiers, but all included
+   here need NULL optional parameters present in the ASN.1.
+
+   See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and
+   "Additional Algorithms and Identifiers for RSA Cryptography for use
+   in the Internet X.509 Public Key Infrastructure Certificate and
+   Certificate Revocation List (CRL) Profile" [RFC4055] for more
+   information.
+
+A.1.1.  sha1WithRSAEncryption
+
+   sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
+
+   Parameters are required, and they must be NULL.
+
+   Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
+   Length = 15
+   0000: 300d 0609 2a86 4886 f70d 0101 0505 00
+
+A.1.2.  sha256WithRSAEncryption
+
+   sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
+
+   Parameters are required, and they must be NULL.
+
+   Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
+   Length = 15
+   0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 12]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+A.1.3.  sha384WithRSAEncryption
+
+   sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
+
+   Parameters are required, and they must be NULL.
+
+   Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
+   Length = 15
+   0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
+
+A.1.4.  sha512WithRSAEncryption
+
+   sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
+
+   Parameters are required, and they must be NULL.
+
+   Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
+   Length = 15
+   0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
+
+A.2.  DSA
+
+   With DSA algorithms, optional parameters are always omitted.  Only
+   algorithm combinations for DSA that are listed in the IANA registry
+   are included.
+
+   See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "PKIX
+   Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758]
+   for more information.
+
+A.2.1.  dsa-with-sha1
+
+   dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+   x9-57(10040) x9algorithm(4) 3 }
+
+   Parameters are absent.
+
+   Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
+   Length = 11
+   0000: 3009 0607 2a86 48ce 3804 03
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 13]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+A.2.2.  dsa-with-sha256
+
+   dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
+   country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
+   id-dsa-with-sha2(3) 2 }
+
+   Parameters are absent.
+
+   Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
+   Length = 13
+   0000: 300b 0609 6086 4801 6503 0403 02
+
+A.3.  ECDSA
+
+   With ECDSA algorithms, the optional parameters are always omitted.
+   Only algorithm combinations for the ECDSA listed in the IANA registry
+   are included.
+
+   See "Elliptic Curve Cryptography Subject Public Key Information"
+   [RFC5480], "Algorithms and Identifiers for PKIX Profile" [RFC3279],
+   and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA"
+   [RFC5758] for more information.
+
+A.3.1.  ecdsa-with-sha1
+
+   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+   ansi-X9-62(10045) signatures(4) 1 }
+
+   Parameters are absent.
+
+   Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
+   Length = 11
+   0000: 3009 0607 2a86 48ce 3d04 01
+
+A.3.2.  ecdsa-with-sha256
+
+   ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
+
+   Parameters are absent.
+
+   Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
+   Length = 12
+   0000: 300a 0608 2a86 48ce 3d04 0302
+
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 14]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+A.3.3.  ecdsa-with-sha384
+
+   ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
+
+   Parameters are absent.
+
+   Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
+   Length = 12
+   0000: 300a 0608 2a86 48ce 3d04 0303
+
+A.3.4.  ecdsa-with-sha512
+
+   ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
+
+   Parameters are absent.
+
+   Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
+   Length = 12
+   0000: 300a 0608 2a86 48ce 3d04 0304
+
+A.4.  RSASSA-PSS
+
+   With RSASSA-PSS, the algorithm object identifier must always be
+   id-RSASSA-PSS, and the hash function and padding parameters are
+   conveyed in the parameters (which are not optional in this case).
+   See Additional RSA Algorithms and Identifiers [RFC4055] for more
+   information.
+
+A.4.1.  RSASSA-PSS with Empty Parameters
+
+   id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
+
+   Parameters are empty, but the ASN.1 part of the sequence must be
+   present.  This means default parameters are used.
+
+   0000 : SEQUENCE
+   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
+   000d :   SEQUENCE
+
+   Length = 15
+   0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
+
+
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 15]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+A.4.2.  RSASSA-PSS with Default Parameters
+
+   id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
+
+   Here the parameters are present and contain the default parameters,
+   i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1,
+   saltLength of 20, and trailerField of 1.
+
+   0000 : SEQUENCE
+   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
+   000d :   SEQUENCE
+   000f :     CONTEXT 0
+   0011 :       SEQUENCE
+   0013 :         OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
+   001a :         NULL
+   001c :     CONTEXT 1
+   001e :       SEQUENCE
+   0020 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
+   002b :         SEQUENCE
+   002d :           OBJECT IDENTIFIER  id-sha1 (1.3.14.3.2.26)
+   0034 :           NULL
+   0036 :     CONTEXT 2
+   0038 :       INTEGER   0x14 (5 bits)
+   003b :     CONTEXT 3
+   003d :       INTEGER   0x1 (1 bits)
+
+   Name = RSASSA-PSS with default parameters,
+          oid = 1.2.840.113549.1.1.10
+   Length = 64
+   0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
+   0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
+   0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
+   0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 16]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+A.4.3.  RSASSA-PSS with SHA-256
+
+   id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
+
+   Here the parameters are present and contain hashAlgorithm of SHA-256,
+   maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.
+
+   0000 : SEQUENCE
+   0002 :   OBJECT IDENTIFIER  RSASSA-PSS (1.2.840.113549.1.1.10)
+   000d :   SEQUENCE
+   000f :     CONTEXT 0
+   0011 :       SEQUENCE
+   0013 :         OBJECT IDENTIFIER  id-sha256 (2.16.840.1.101.3.4.2.1)
+   001e :         NULL
+   0020 :     CONTEXT 1
+   0022 :       SEQUENCE
+   0024 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
+   002f :         SEQUENCE
+   0031 :           OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
+   003c :           NULL
+   003e :     CONTEXT 2
+   0040 :       INTEGER   0x20 (6 bits)
+   0043 :     CONTEXT 3
+   0045 :       INTEGER   0x1 (1 bits)
+
+   Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
+   Length = 72
+   0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
+   0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
+   0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
+   0030: 0d06 0960 8648 0165 0304 0201 0500 a203
+   0040: 0201 20a3 0302 0101
+
+Appendix B.  IKEv2 Payload Example
+
+B.1.  sha1WithRSAEncryption
+
+   The IKEv2 AUTH payload would start like this:
+
+   00000000: NN00 00LL 0e00 0000 0f30 0d06 092a 8648
+   00000010: 86f7 0d01 0105 0500 ....
+
+   Where the NN will be the next payload type (i.e., the value depends
+   on the next payload after this Authentication payload), the LL will
+   be the length of this payload, and after the sha1WithRSAEncryption
+   ASN.1 block (15 bytes) there will be the actual signature, which is
+   omitted here.
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 17]
+
+RFC 7427            Signature Authentication in IKEv2       January 2015
+
+
+Acknowledgements
+
+   Most of this work was based on the work done in the IPsecME design
+   team for the ECDSA.  The design team members were: Dan Harkins,
+   Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
+
+Authors' Addresses
+
+   Tero Kivinen
+   INSIDE Secure
+   Eerikinkatu 28
+   Helsinki  FI-00180
+   Finland
+
+   EMail: kivinen@iki.fi
+
+
+   Joel Snyder
+   Opus One
+   1404 East Lind Road
+   Tucson, AZ  85719
+
+   Phone: +1 520 324 0494
+   EMail: jms@opus1.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kivinen & Snyder             Standards Track                   [Page 18]
+