doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        J. Schiller
   8 Request for Comments: 4307         Massachusetts Institute of Technology
   9 Category: Standards Track                                  December 2005
  10
  11
  12                 Cryptographic Algorithms for Use in the
  13                 Internet Key Exchange Version 2 (IKEv2)
  14
  15 Status of This Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2005).
  26
  27 Abstract
  28
  29    The IPsec series of protocols makes use of various cryptographic
  30    algorithms in order to provide security services.  The Internet Key
  31    Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
  32    which algorithms should be used in any given association.  However,
  33    to ensure interoperability between disparate implementations, it is
  34    necessary to specify a set of mandatory-to-implement algorithms to
  35    ensure that there is at least one algorithm that all implementations
  36    will have available.  This document defines the current set of
  37    algorithms that are mandatory to implement as part of IKEv2, as well
  38    as algorithms that should be implemented because they may be promoted
  39    to mandatory at some future time.
  40
  41 1.  Introduction
  42
  43    The Internet Key Exchange protocol provides for the negotiation of
  44    cryptographic algorithms between both endpoints of a cryptographic
  45
  46    association.  Different implementations of IPsec and IKE may provide
  47    different algorithms.  However, the IETF desires that all
  48    implementations should have some way to interoperate.  In particular,
  49    this requires that IKE define a set of mandatory-to-implement
  50    algorithms because IKE itself uses such algorithms as part of its own
  51    negotiations.  This requires that some set of algorithms be specified
  52    as "mandatory-to-implement" for IKE.
  53
  54
  55
  56
  57
  58 Schiller                    Standards Track                     [Page 1]
  59 \f
  60 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
  61
  62
  63    The nature of cryptography is that new algorithms surface
  64    continuously and existing algorithms are continuously attacked.  An
  65    algorithm believed to be strong today may be demonstrated to be weak
  66    tomorrow.  Given this, the choice of mandatory-to-implement algorithm
  67    should be conservative so as to minimize the likelihood of it being
  68    compromised quickly.  Thought should also be given to performance
  69    considerations as many uses of IPsec will be in environments where
  70    performance is a concern.
  71
  72    Finally, we need to recognize that the mandatory-to-implement
  73    algorithm(s) may need to change over time to adapt to the changing
  74    world.  For this reason, the selection of mandatory-to-implement
  75    algorithms was removed from the main IKEv2 specification and placed
  76    in this document.  As the choice of algorithm changes, only this
  77    document should need to be updated.
  78
  79    Ideally, the mandatory-to-implement algorithm of tomorrow should
  80    already be available in most implementations of IPsec by the time it
  81    is made mandatory.  To facilitate this, we will attempt to identify
  82    those algorithms (that are known today) in this document.  There is
  83    no guarantee that the algorithms we believe today may be mandatory in
  84    the future will in fact become so.  All algorithms known today are
  85    subject to cryptographic attack and may be broken in the future.
  86
  87 2.  Requirements Terminology
  88
  89    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
  90    "MAY" that appear in this document are to be interpreted as described
  91    in [RFC2119].
  92
  93    We define some additional terms here:
  94
  95    SHOULD+    This term means the same as SHOULD.  However, it is likely
  96               that an algorithm marked as SHOULD+ will be promoted at
  97               some future time to be a MUST.
  98
  99    SHOULD-    This term means the same as SHOULD.  However, an algorithm
 100               marked as SHOULD- may be deprecated to a MAY in a future
 101               version of this document.
 102
 103    MUST-      This term means the same as MUST.  However, we expect at
 104               some point that this algorithm will no longer be a MUST in
 105               a future document.  Although its status will be determined
 106               at a later time, it is reasonable to expect that if a
 107               future revision of a document alters the status of a MUST-
 108               algorithm, it will remain at least a SHOULD or a SHOULD-.
 109
 110
 111
 112
 113
 114 Schiller                    Standards Track                     [Page 2]
 115 \f
 116 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
 117
 118
 119 3.  Algorithm Selection
 120
 121 3.1.  IKEv2 Algorithm Selection
 122
 123 3.1.1.  Encrypted Payload Algorithms
 124
 125    The IKEv2 Encrypted Payload requires both a confidentiality algorithm
 126    and an integrity algorithm.  For confidentiality, implementations
 127    MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC.  For
 128    integrity, HMAC-SHA1 MUST be implemented.
 129
 130 3.1.2.  Diffie-Hellman Groups
 131
 132    There are several Modular Exponential (MODP) groups that are defined
 133    for use in IKEv2.  They are defined in both the [IKEv2] base document
 134    and in the MODP extensions document.  They are identified by group
 135    number.  Any groups not listed here are considered as "MAY be
 136    implemented".
 137
 138       Group Number        Bit Length            Status     Defined
 139       2                   1024 MODP Group       MUST-      [RFC2409]
 140       14                  2048 MODP Group       SHOULD+    [RFC3526]
 141
 142 3.1.3.  IKEv2 Transform Type 1 Algorithms
 143
 144    IKEv2 defines several possible algorithms for Transfer Type 1
 145    (encryption).  These are defined below with their implementation
 146    status.
 147
 148       Name                     Number    Defined In      Status
 149       RESERVED                 0
 150       ENCR_3DES                3         [RFC2451]       MUST-
 151       ENCR_NULL                11        [RFC2410]       MAY
 152       ENCR_AES_CBC             12        [AES-CBC]       SHOULD+
 153       ENCR_AES_CTR             13        [AES-CTR]       SHOULD
 154
 155 3.1.4.  IKEv2 Transform Type 2 Algorithms
 156
 157    Transfer Type 2 Algorithms are pseudo-random functions used to
 158    generate random values when needed.
 159
 160       Name                Number     Defined In   Status
 161       RESERVED            0
 162       PRF_HMAC_MD5        1          [RFC2104]    MAY
 163       PRF_HMAC_SHA1       2          [RFC2104]    MUST
 164       PRF_AES128_CBC      4          [AESPRF]     SHOULD+
 165
 166
 167
 168
 169
 170 Schiller                    Standards Track                     [Page 3]
 171 \f
 172 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
 173
 174
 175 3.1.5.  IKEv2 Transform Type 3 Algorithms
 176
 177    Transfer Type 3 Algorithms are Integrity algorithms used to protect
 178    data against tampering.
 179
 180       Name                     Number       Defined In           Status
 181       NONE                     0
 182       AUTH_HMAC_MD5_96         1            [RFC2403]            MAY
 183       AUTH_HMAC_SHA1_96        2            [RFC2404]            MUST
 184       AUTH_AES_XCBC_96         5            [AES-MAC]            SHOULD+
 185
 186 4.  Security Considerations
 187
 188    The security of cryptographic-based systems depends on both the
 189    strength of the cryptographic algorithms chosen and the strength of
 190    the keys used with those algorithms.  The security also depends on
 191    the engineering of the protocol used by the system to ensure that
 192    there are no non-cryptographic ways to bypass the security of the
 193    overall system.
 194
 195    This document concerns itself with the selection of cryptographic
 196    algorithms for the use of IKEv2, specifically with the selection of
 197    "mandatory-to-implement" algorithms.  The algorithms identified in
 198    this document as "MUST implement" or "SHOULD implement" are not known
 199    to be broken at the current time, and cryptographic research so far
 200    leads us to believe that they will likely remain secure into the
 201    foreseeable future.  However, this isn't necessarily forever.  We
 202    would therefore expect that new revisions of this document will be
 203    issued from time to time that reflect the current best practice in
 204    this area.
 205
 206 5.  Normative References
 207
 208    [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
 209                 (IKE)", RFC 2409, November 1998.
 210
 211    [IKEv2]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
 212                 Protocol", RFC 4306, December 2005.
 213
 214    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
 215                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 216
 217    [RFC3526]    Kivinen, T. and M. Kojo, "More Modular Exponential
 218                 (MODP) Diffie-Hellman groups for Internet Key Exchange
 219                 (IKE)", RFC 3526, May 2003.
 220
 221    [RFC2451]    Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
 222                 Algorithms", RFC 2451, November 1998.
 223
 224
 225
 226 Schiller                    Standards Track                     [Page 4]
 227 \f
 228 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
 229
 230
 231    [RFC2410]    Glenn, R. and S. Kent, "The NULL Encryption Algorithm
 232                 and Its Use With IPsec", RFC 2410, November 1998.
 233
 234    [AES-CBC]    Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
 235                 Cipher Algorithm and Its Use with IPsec", RFC 3602,
 236                 September 2003.
 237
 238    [AES-CTR]    Housley, R., "Using Advanced Encryption Standard (AES)
 239                 Counter Mode With IPsec Encapsulating Security Payload
 240                 (ESP)", RFC 3686, January 2004.
 241
 242    [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
 243                 Keyed-Hashing for Message Authentication", RFC 2104,
 244                 February 1997.
 245
 246    [AESPRF]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
 247                 Internet Key Exchange Protocol (IKE)", RFC 3664, January
 248                 2004.
 249
 250    [RFC2403]    Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
 251                 ESP and AH", RFC 2403, November 1998.
 252
 253    [RFC2404]    Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
 254                 within ESP and AH", RFC 2404, November 1998.
 255
 256    [AES-MAC]    Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
 257                 Algorithm and Its Use With IPsec", RFC 3566, September
 258                 2003.
 259
 260 Author's Address
 261
 262    Jeffrey I. Schiller
 263    Massachusetts Institute of Technology
 264    Room W92-190
 265    77 Massachusetts Avenue
 266    Cambridge, MA 02139-4307
 267    USA
 268
 269    Phone: +1 (617) 253-0161
 270    EMail: jis@mit.edu
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Schiller                    Standards Track                     [Page 5]
 283 \f
 284 RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2005).
 290
 291    This document is subject to the rights, licenses and restrictions
 292    contained in BCP 78, and except as set forth therein, the authors
 293    retain all their rights.
 294
 295    This document and the information contained herein are provided on an
 296    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 297    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 298    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 299    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 300    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 301    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 302
 303 Intellectual Property
 304
 305    The IETF takes no position regarding the validity or scope of any
 306    Intellectual Property Rights or other rights that might be claimed to
 307    pertain to the implementation or use of the technology described in
 308    this document or the extent to which any license under such rights
 309    might or might not be available; nor does it represent that it has
 310    made any independent effort to identify any such rights.  Information
 311    on the procedures with respect to rights in RFC documents can be
 312    found in BCP 78 and BCP 79.
 313
 314    Copies of IPR disclosures made to the IETF Secretariat and any
 315    assurances of licenses to be made available, or the result of an
 316    attempt made to obtain a general license or permission for the use of
 317    such proprietary rights by implementers or users of this
 318    specification can be obtained from the IETF on-line IPR repository at
 319    http://www.ietf.org/ipr.
 320
 321    The IETF invites any interested party to bring to its attention any
 322    copyrights, patents or patent applications, or other proprietary
 323    rights that may cover technology that may be required to implement
 324    this standard.  Please address the information to the IETF at ietf-
 325    ipr@ietf.org.
 326
 327 Acknowledgement
 328
 329    Funding for the RFC Editor function is currently provided by the
 330    Internet Society.
 331
 332
 333
 334
 335
 336
 337
 338 Schiller                    Standards Track                     [Page 6]
 339 \f