added often used RFCs and drafts

src/charon/doc/Todo-list.txt

@@ -74,3 +74,7 @@ Todo-List for charon
 - add support for CERTREQs
 - proper handling of multiple certificate payloads (import order)
 - add a Rekey-Counter for SAs in "statusall"
+- ipsec status: 
+  - on one line: ip, id, spi
+  - no key age, rekey for IKE
+  - byte count

src/charon/doc/standards/draft-myers-ikev2-ocsp-03.txt

@@ -0,0 +1,785 @@
+
+
+
+Network Working Group                                           M. Myers
+Internet-Draft                                   TraceRoute Security LLC
+Expires: January 12, 2007                                  H. Tschofenig
+                                                                 Siemens
+                                                           July 11, 2006
+
+
+                        OCSP Extensions to IKEv2
+                     draft-myers-ikev2-ocsp-03.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 12, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   While IKEv2 supports public key based authentication (PKI), the
+   corresponding use of in-band CRLs is problematic due to unbounded CRL
+   size.  The size of an OCSP response is however well-bounded and
+   small.  This document defines the "OCSP Content" extension to IKEv2.
+   A CERTREQ payload with "OCSP Content" identifies one or more trusted
+   OCSP responders and is a request for inclusion of an OCSP response in
+   the IKEv2 handshake.  A cooperative recipient of such a request
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 1]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+   responds with a CERT payload containing the appropriate OCSP
+   response.  This content is recognizable via the same "OCSP Content"
+   identifier.
+
+   When certificates are used with IKEv2, the communicating peers need a
+   mechanism to determine the revocation status of the peer's
+   certificate.  OCSP is one such mechanism.  This document applies when
+   OCSP is desired and security policy prevents one of the IKEv2 peers
+   from accessing the relevant OCSP responder directly.  Firewalls are
+   often deployed in a manner that prevents such access by IKEv2 peers
+   outside of an enterprise network.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Extension Definition . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  OCSP Request . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.2.  OCSP Response  . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Extension Requirements . . . . . . . . . . . . . . . . . . . .  6
+     4.1.  OCSP Request . . . . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  OCSP Response  . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Examples and Discussion  . . . . . . . . . . . . . . . . . . .  8
+     5.1.  Peer to Peer . . . . . . . . . . . . . . . . . . . . . . .  8
+     5.2.  Extended Authentication Protocol (EAP) . . . . . . . . . .  9
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
+   Intellectual Property and Copyright Statements . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 2]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+1.  Introduction
+
+   Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
+   supports a range of authentication mechanisms, including the use of
+   public key based authentication.  Confirmation of certificate
+   reliability is essential to achieve the security assurances public
+   key cryptography provides.  One fundamental element of such
+   confirmation is reference to certificate revocation status (see
+   [RFC3280] for additional detail).
+
+   The historic means of determining certificate revocation status is
+   through the use of Certificate Revocation Lists (CRLs).  IKEv2 allows
+   CRLs to be exchanged in-band via the CERT payload.
+
+   CRLs can however grow unbounded in size.  Many real-world examples
+   exist to demonstrate the impracticality of including a multi-megabyte
+   file in an IKE exchange.  This constraint is particularly acute in
+   bandwidth limited environments (e.g., mobile communications).  The
+   net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
+   acquisition of these data, should they even be used at all.
+
+   Reliance on OOB methods can be further complicated if access to
+   revocation data requires use of IPsec (and therefore IKE) to
+   establish secure and authorized access to the CRLs of an IKE
+   participant.  Such network access deadlock further contributes to a
+   reduced reliance on certificate revocation status in favor of blind
+   trust.
+
+   OCSP [RFC2560] offers a useful alternative.  The size of an OCSP
+   response is bounded and small and therefore suitable for in-band
+   IKEv2 signaling of a certificate's revocation status.
+
+   This document defines an extension to IKEv2 that enables the use of
+   OCSP for in-band signaling of certificate revocation status.  A new
+   content encoding is defined for use in the CERTREQ and CERT payloads.
+   A CERTREQ payload with "OCSP Content" identifies one or more trusted
+   OCSP responders and is a request for inclusion of an OCSP response in
+   the IKEv2 handshake.  A cooperative recipient of such a request
+   responds with a CERT payload containing the appropriate OCSP
+   response.  This content is recognizable via the same "OCSP Content"
+   identifier.
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 3]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+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 RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 4]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+3.  Extension Definition
+
+   With reference to Section 3.6 of [IKEv2], the values for the Cert
+   Encoding field of the CERT payload are extended as follows (see also
+   the IANA Considerations section of this document):
+
+               Certificate Encoding               Value
+               --------------------               -----
+               OCSP Content                        14
+
+3.1.  OCSP Request
+
+   A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
+   Payload indicates the presence of one or more OCSP Responder
+   certificate hashes in the Certificate Authority field of the CERTREQ
+   payload.
+
+   The presence of OCSP Content (14) in a CERTREQ message:
+
+   1.  identifies one or more OCSP responders trusted by the sender;
+
+   2.  notifies the recipient of sender's support for the OCSP extension
+       to IKEv2; and
+
+   3.  notifies the recipient of sender's desire to receive OCSP
+       confirmation in a subsequent CERT payload.
+
+3.2.  OCSP Response
+
+   A value of OCSP Content (14) in the Cert Encoding field of a CERT
+   Payload indicates the presence of an OCSP Response in the Certificate
+   Data field of the CERT payload.
+
+   Correlation between an OCSP Response CERT payload and a corresponding
+   CERT payload carrying a certificate can be achieved by matching the
+   OCSP response CertID field to the certificate.  See [RFC2560] for the
+   definition of OCSP response content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 5]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+4.  Extension Requirements
+
+4.1.  OCSP Request
+
+   Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
+   hashes as the Certification Authority value of a single CERTREQ
+   message.  There is no means however to indicate which among those
+   hashes relates to the certificate of a trusted OCSP responder.
+
+   Therefore an OCSP Request as defined in Section 3.1 above SHALL be
+   transmitted separate from any other CERTREQ payloads in an IKEv2
+   exchange.
+
+   Where it is useful to identify more than one trusted OCSP responder,
+   each such identification SHALL be concatenated in a manner identical
+   to the method documented in Section 3.7 of [IKEv2] regarding the
+   assembly of multiple trust anchor hashes.
+
+   The Certification Authority value in an OCSP Request CERTREQ SHALL be
+   computed and produced in a manner identical to that of trust anchor
+   hashes as documented in Section 3.7 of [IKEv2].
+
+   Upon receipt of an OCSP Response CERT payload corresponding to a
+   prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the
+   OCSP response into path validation logic defined by [RFC3280].
+
+   The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if
+   either:
+
+   1.  the corresponding OCSP Response CERT payload indicates that the
+       subject certificate is revoked; OR
+
+   2.  the corresponding OCSP Response CERT payload indicates an OCSP
+       error (e.g., malformedRequest, internalError, tryLater,
+       sigRequired, unauthorized, etc.).
+
+   The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange
+   if a corresponding OCSP Response CERT payload is not received.  This
+   might be an indication that this OCSP extension is not supported.
+
+4.2.  OCSP Response
+
+   Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD
+   acquire the related OCSP-based assertion and produce and transmit an
+   OCSP Response CERT payload corresponding to the certificate needed to
+   verify its signature on IKEv2 payloads.
+
+   An OCSP Response CERT payload SHALL be transmitted separate from any
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 6]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+   other CERT payload in an IKEv2 exchange.
+
+   The means by which an OCSP response may be acquired for production of
+   an OCSP Response CERT payload is out of scope of this document.
+
+   The structure and encoding of the Certificate Data field of an OCSP
+   Response CERT payload SHALL be identical to that defined in
+   [RFC2560].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 7]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+5.  Examples and Discussion
+
+   This section shows the standard IKEv2 message examples with both
+   peers, the initiator and the responder, using public key based
+   authentication, CERTREQ and CERT payloads.  The first instance
+   corresponds to Section 1.2 of [IKEv2], the illustrations of which are
+   reproduced below for reference.
+
+5.1.  Peer to Peer
+
+   Application of the IKEv2 extensions defined in this document to the
+   peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
+   follows.  Messages are numbered for ease of reference.
+
+
+        Initiator                             Responder
+        -----------                           -----------
+   (1)  HDR, SAi1, KEi, Ni              -->
+
+   (2)                                  <-- HDR, SAr1, KEr, Nr,
+                                            CERTREQ(OCSP Request)
+   (3)  HDR, SK {IDi, CERT(certificate),-->
+        CERT(OCSP Response),
+        CERTREQ(OCSP Request),
+        [IDr,] AUTH, SAi2, TSi, TSr}
+
+   (4)                                  <-- HDR, SK {IDr,
+                                            CERT(certificate),
+                                            CERT(OCSP Response),
+                                            AUTH, SAr2, TSi, TSr}
+
+   In (2) Responder sends an OCSP Request CERTREQ payload identifying
+   one or more OCSP responders trusted by Responder.  In response,
+   Initiator sends in (3) both a CERT payload carrying its certificate
+   and an OCSP Response CERT payload covering that certificate.  In (3)
+   Initiator also requests an OCSP response via the OCSP Request CERTREQ
+   payload.  In (4) Responder returns its certificate and a separate
+   OCSP Response CERT payload covering that certificate.
+
+   It is important to note that in this scenario, the Responder in (2)
+   does not yet possess the Initiator's certificate and therefore cannot
+   form an OCSP request.  [RFC2560] allows for pre-produced responses.
+   It is thus easily inferred that OCSP responses can be produced in the
+   absence of a corresponding request (OCSP nonces notwithstanding).  In
+   such instances OCSP Requests are simply index values into these data.
+
+   It is also important in extending IKEv2 towards OCSP in this scenario
+   that the Initiator has certain knowledge that the Responder is
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 8]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+   capable of and willing to participate in the extension.  Yet the
+   Responder will only trust one or more OCSP responder signatures.
+   These factors motivate the definition of OCSP Responder Hash
+   extension.
+
+5.2.  Extended Authentication Protocol (EAP)
+
+   Another scenario of pressing interest is the use of EAP to
+   accommodate multiple end users seeking enterprise access to an IPsec
+   gateway.  As with the preceding section, the following illustration
+   is extracted from [IKEv2].  In the event of a conflict between this
+   document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
+   dominate.
+
+
+        Initiator                            Responder
+        -----------                          -----------
+   (1)  HDR, SAi1, KEi, Ni              -->
+   (2)                                  <-- HDR, SAr1, KEr, Nr
+   (3)  HDR, SK {IDi,                   -->
+        CERTREQ(OCSP Request),
+        [IDr,] AUTH, SAi2, TSi, TSr}
+   (4)                                  <-- HDR, SK {IDr,
+                                            CERT(certificate),
+                                            CERT(OCSP Response),
+                                            AUTH, EAP}
+   (5)       HDR, SK {EAP}              -->
+
+   (6)                                  <-- HDR, SK {EAP (success)}
+
+   (7)       HDR, SK {AUTH}             -->
+
+   (8)                                  <-- HDR, SK {AUTH, SAr2, TSi,
+                                            TSr }
+
+   In the EAP scenario, messages (5) through (8) are not relevant to
+   this document.  Note that while [IKEv2] allows for the optional
+   inclusion of a CERTREQ in (2), this document asserts no need of its
+   use.  It is assumed that environments including this optional payload
+   and yet wishing to implement the OCSP extension to IKEv2 are
+   sufficiently robust as to accommodate this redundant payload.
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007                [Page 9]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+6.  Security Considerations
+
+   For the reasons noted above, OCSP request as defined in Section 3.1
+   is used in place of OCSP request syntax to trigger production and
+   transmission of an OCSP response.  OCSP as defined in [RFC2560] may
+   contain a nonce request extension to improve security against replay
+   attacks (see Section 4.4.1 of [RFC2560] for further details).  The
+   OCSP Request defined by this document cannot accommodate nonces.
+   [RFC2560] deals with this aspect by allowing pre-produced responses.
+
+   [RFC2560] points to this replay vulnerability and indicates: "The use
+   of precomputed responses allows replay attacks in which an old (good)
+   response is replayed prior to its expiration date but after the
+   certificate has been revoked.  Deployments of OCSP should carefully
+   evaluate the benefit of precomputed responses against the probability
+   of a replay attack and the costs associated with its successful
+   execution."  Nodes SHOULD make the required freshness of an OCSP
+   Response configurable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007               [Page 10]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+7.  IANA Considerations
+
+   This document defines one new field type for use in the IKEv2 Cert
+   Encoding field of the Certificate Payload format.  Official
+   assignment of the "OCSP Content" extension to the Cert Encoding table
+   of Section 3.6 of [IKEv2] needs to be acquired from IANA.
+
+               Certificate Encoding               Value
+               --------------------               -----
+               OCSP Content                        14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007               [Page 11]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+8.  Acknowledgements
+
+   The authors would like to thank Russ Housley for his support.
+   Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
+   Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
+   review.
+
+9.  Normative References
+
+   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+              RFC 4306, December 2005.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+              Adams, "X.509 Internet Public Key Infrastructure Online
+              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007               [Page 12]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+Authors' Addresses
+
+   Michael Myers
+   TraceRoute Security LLC
+
+
+   Email: [email protected]
+
+
+   Hannes Tschofenig
+   Siemens
+   Otto-Hahn-Ring 6
+   Munich, Bavaria  81739
+   Germany
+
+   Email: [email protected]
+   URI:   http://www.tschofenig.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007               [Page 13]
+
+Internet-Draft          OCSP Extensions to IKEv2               July 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   [email protected].
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Myers & Tschofenig      Expires January 12, 2007               [Page 14]
+
+

src/charon/doc/standards/rfc4307.txt

@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        J. Schiller
+Request for Comments: 4307         Massachusetts Institute of Technology
+Category: Standards Track                                  December 2005
+
+
+                Cryptographic Algorithms for Use in the
+                Internet Key Exchange Version 2 (IKEv2)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The IPsec series of protocols makes use of various cryptographic
+   algorithms in order to provide security services.  The Internet Key
+   Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
+   which algorithms should be used in any given association.  However,
+   to ensure interoperability between disparate implementations, it is
+   necessary to specify a set of mandatory-to-implement algorithms to
+   ensure that there is at least one algorithm that all implementations
+   will have available.  This document defines the current set of
+   algorithms that are mandatory to implement as part of IKEv2, as well
+   as algorithms that should be implemented because they may be promoted
+   to mandatory at some future time.
+
+1.  Introduction
+
+   The Internet Key Exchange protocol provides for the negotiation of
+   cryptographic algorithms between both endpoints of a cryptographic
+
+   association.  Different implementations of IPsec and IKE may provide
+   different algorithms.  However, the IETF desires that all
+   implementations should have some way to interoperate.  In particular,
+   this requires that IKE define a set of mandatory-to-implement
+   algorithms because IKE itself uses such algorithms as part of its own
+   negotiations.  This requires that some set of algorithms be specified
+   as "mandatory-to-implement" for IKE.
+
+
+
+
+
+Schiller                    Standards Track                     [Page 1]
+
+RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
+
+
+   The nature of cryptography is that new algorithms surface
+   continuously and existing algorithms are continuously attacked.  An
+   algorithm believed to be strong today may be demonstrated to be weak
+   tomorrow.  Given this, the choice of mandatory-to-implement algorithm
+   should be conservative so as to minimize the likelihood of it being
+   compromised quickly.  Thought should also be given to performance
+   considerations as many uses of IPsec will be in environments where
+   performance is a concern.
+
+   Finally, we need to recognize that the mandatory-to-implement
+   algorithm(s) may need to change over time to adapt to the changing
+   world.  For this reason, the selection of mandatory-to-implement
+   algorithms was removed from the main IKEv2 specification and placed
+   in this document.  As the choice of algorithm changes, only this
+   document should need to be updated.
+
+   Ideally, the mandatory-to-implement algorithm of tomorrow should
+   already be available in most implementations of IPsec by the time it
+   is made mandatory.  To facilitate this, we will attempt to identify
+   those algorithms (that are known today) in this document.  There is
+   no guarantee that the algorithms we believe today may be mandatory in
+   the future will in fact become so.  All algorithms known today are
+   subject to cryptographic attack and may be broken in the future.
+
+2.  Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
+   "MAY" that appear in this document are to be interpreted as described
+   in [RFC2119].
+
+   We define some additional terms here:
+
+   SHOULD+    This term means the same as SHOULD.  However, it is likely
+              that an algorithm marked as SHOULD+ will be promoted at
+              some future time to be a MUST.
+
+   SHOULD-    This term means the same as SHOULD.  However, an algorithm
+              marked as SHOULD- may be deprecated to a MAY in a future
+              version of this document.
+
+   MUST-      This term means the same as MUST.  However, we expect at
+              some point that this algorithm will no longer be a MUST in
+              a future document.  Although its status will be determined
+              at a later time, it is reasonable to expect that if a
+              future revision of a document alters the status of a MUST-
+              algorithm, it will remain at least a SHOULD or a SHOULD-.
+
+
+
+
+
+Schiller                    Standards Track                     [Page 2]
+
+RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
+
+
+3.  Algorithm Selection
+
+3.1.  IKEv2 Algorithm Selection
+
+3.1.1.  Encrypted Payload Algorithms
+
+   The IKEv2 Encrypted Payload requires both a confidentiality algorithm
+   and an integrity algorithm.  For confidentiality, implementations
+   MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC.  For
+   integrity, HMAC-SHA1 MUST be implemented.
+
+3.1.2.  Diffie-Hellman Groups
+
+   There are several Modular Exponential (MODP) groups that are defined
+   for use in IKEv2.  They are defined in both the [IKEv2] base document
+   and in the MODP extensions document.  They are identified by group
+   number.  Any groups not listed here are considered as "MAY be
+   implemented".
+
+      Group Number        Bit Length            Status     Defined
+      2                   1024 MODP Group       MUST-      [RFC2409]
+      14                  2048 MODP Group       SHOULD+    [RFC3526]
+
+3.1.3.  IKEv2 Transform Type 1 Algorithms
+
+   IKEv2 defines several possible algorithms for Transfer Type 1
+   (encryption).  These are defined below with their implementation
+   status.
+
+      Name                     Number    Defined In      Status
+      RESERVED                 0
+      ENCR_3DES                3         [RFC2451]       MUST-
+      ENCR_NULL                11        [RFC2410]       MAY
+      ENCR_AES_CBC             12        [AES-CBC]       SHOULD+
+      ENCR_AES_CTR             13        [AES-CTR]       SHOULD
+
+3.1.4.  IKEv2 Transform Type 2 Algorithms
+
+   Transfer Type 2 Algorithms are pseudo-random functions used to
+   generate random values when needed.
+
+      Name                Number     Defined In   Status
+      RESERVED            0
+      PRF_HMAC_MD5        1          [RFC2104]    MAY
+      PRF_HMAC_SHA1       2          [RFC2104]    MUST
+      PRF_AES128_CBC      4          [AESPRF]     SHOULD+
+
+
+
+
+
+Schiller                    Standards Track                     [Page 3]
+
+RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
+
+
+3.1.5.  IKEv2 Transform Type 3 Algorithms
+
+   Transfer Type 3 Algorithms are Integrity algorithms used to protect
+   data against tampering.
+
+      Name                     Number       Defined In           Status
+      NONE                     0
+      AUTH_HMAC_MD5_96         1            [RFC2403]            MAY
+      AUTH_HMAC_SHA1_96        2            [RFC2404]            MUST
+      AUTH_AES_XCBC_96         5            [AES-MAC]            SHOULD+
+
+4.  Security Considerations
+
+   The security of cryptographic-based systems depends on both the
+   strength of the cryptographic algorithms chosen and the strength of
+   the keys used with those algorithms.  The security also depends on
+   the engineering of the protocol used by the system to ensure that
+   there are no non-cryptographic ways to bypass the security of the
+   overall system.
+
+   This document concerns itself with the selection of cryptographic
+   algorithms for the use of IKEv2, specifically with the selection of
+   "mandatory-to-implement" algorithms.  The algorithms identified in
+   this document as "MUST implement" or "SHOULD implement" are not known
+   to be broken at the current time, and cryptographic research so far
+   leads us to believe that they will likely remain secure into the
+   foreseeable future.  However, this isn't necessarily forever.  We
+   would therefore expect that new revisions of this document will be
+   issued from time to time that reflect the current best practice in
+   this area.
+
+5.  Normative References
+
+   [RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
+                (IKE)", RFC 2409, November 1998.
+
+   [IKEv2]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+                Protocol", RFC 4306, December 2005.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3526]    Kivinen, T. and M. Kojo, "More Modular Exponential
+                (MODP) Diffie-Hellman groups for Internet Key Exchange
+                (IKE)", RFC 3526, May 2003.
+
+   [RFC2451]    Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+                Algorithms", RFC 2451, November 1998.
+
+
+
+Schiller                    Standards Track                     [Page 4]
+
+RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
+
+
+   [RFC2410]    Glenn, R. and S. Kent, "The NULL Encryption Algorithm
+                and Its Use With IPsec", RFC 2410, November 1998.
+
+   [AES-CBC]    Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
+                Cipher Algorithm and Its Use with IPsec", RFC 3602,
+                September 2003.
+
+   [AES-CTR]    Housley, R., "Using Advanced Encryption Standard (AES)
+                Counter Mode With IPsec Encapsulating Security Payload
+                (ESP)", RFC 3686, January 2004.
+
+   [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+                Keyed-Hashing for Message Authentication", RFC 2104,
+                February 1997.
+
+   [AESPRF]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
+                Internet Key Exchange Protocol (IKE)", RFC 3664, January
+                2004.
+
+   [RFC2403]    Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
+                ESP and AH", RFC 2403, November 1998.
+
+   [RFC2404]    Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+                within ESP and AH", RFC 2404, November 1998.
+
+   [AES-MAC]    Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
+                Algorithm and Its Use With IPsec", RFC 3566, September
+                2003.
+
+Author's Address
+
+   Jeffrey I. Schiller
+   Massachusetts Institute of Technology
+   Room W92-190
+   77 Massachusetts Avenue
+   Cambridge, MA 02139-4307
+   USA
+
+   Phone: +1 (617) 253-0161
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+Schiller                    Standards Track                     [Page 5]
+
+RFC 4307             IKEv2 Cryptographic Algorithms        December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   [email protected].
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Schiller                    Standards Track                     [Page 6]
+

src/charon/doc/standards/rfc4478.txt

@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                             Y. Nir
+Request for Comments: 4478                                   Check Point
+Category: Experimental                                        April 2006
+
+
+   Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document extends the Internet Key Exchange (IKEv2) Protocol
+   document [IKEv2].  With some IPsec peers, particularly in the remote
+   access scenario, it is desirable to repeat the mutual authentication
+   periodically.  The purpose of this is to limit the time that security
+   associations (SAs) can be used by a third party who has gained
+   control of the IPsec peer.  This document describes a mechanism to
+   perform this function.
+
+1.  Introduction
+
+   In several cases, such as the remote access scenario, policy dictates
+   that the mutual authentication needs to be repeated periodically.
+   Repeated authentication can usually be achieved by simply repeating
+   the Initial exchange by whichever side has a stricter policy.
+
+   However, in the remote access scenario it is usually up to a human
+   user to supply the authentication credentials, and often Extensible
+   Authentication Protocol (EAP) is used for authentication, which makes
+   it unreasonable or impossible for the remote access gateway to
+   initiate the IKEv2 exchange.
+
+   This document describes a new notification that the original
+   Responder can send to the original Initiator with the number of
+   seconds before the authentication needs to be repeated.  The
+   Initiator SHOULD repeat the Initial exchange before that time is
+   expired.  If the Initiator fails to do so, the Responder may close
+   all Security Associations.
+
+
+
+
+Nir                           Experimental                      [Page 1]
+
+RFC 4478            Repeated Authentication in IKEv2          April 2006
+
+
+   Repeated authentication is not the same as IKE SA rekeying, and need
+   not be tied to it.  The key words "MUST", "MUST NOT", "SHOULD",
+   "SHOULD NOT", and "MAY" in this document are to be interpreted as
+   described in [RFC2119].
+
+2.  Authentication Lifetime
+
+   The Responder in an IKEv2 negotiation MAY be configured to limit the
+   time that an IKE SA and the associated IPsec SAs may be used before
+   the peer is required to repeat the authentication, through a new
+   Initial Exchange.
+
+   The Responder MUST send this information to the Initiator in an
+   AUTH_LIFETIME notification either in the last message of an IKE_AUTH
+   exchange, or in an INFORMATIONAL request, which may be sent at any
+   time.
+
+   When sent as part of the IKE SA setup, the AUTH_LIFETIME notification
+   is used as follows:
+
+      Initiator                            Responder
+      -------------------------------      -----------------------------
+      HDR, SAi1, KEi, Ni              -->
+                                      <--  HDR, SAr1, KEr, Nr, [CERTREQ]
+      HDR, SK {IDi, [CERT,] [CERTREQ,]
+         [IDr,] AUTH, SAi2, TSi, TSr} -->
+                                      <--  HDR, SK {IDr, [CERT,] AUTH,
+                                                    SAr2, TSi, TSr,
+                                                     N(AUTH_LIFETIME)}
+
+   The separate Informational exchange is formed as follows:
+
+                                      <--  HDR, SK {N(AUTH_LIFETIME)}
+      HDR  SK {}                      -->
+
+   The AUTH_LIFETIME notification is described in Section 3.
+
+   The original Responder that sends the AUTH_LIFETIME notification
+   SHOULD send a DELETE notification soon after the end of the lifetime
+   period, unless the IKE SA is deleted before the lifetime period
+   elapses.  If the IKE SA is rekeyed, then the time limit applies to
+   the new SA.
+
+   An Initiator that received an AUTH_LIFETIME notification SHOULD
+   repeat the Initial exchange within the time indicated in the
+   notification.  The time is measured from the time that the original
+   Initiator receives the notification.
+
+
+
+
+Nir                           Experimental                      [Page 2]
+
+RFC 4478            Repeated Authentication in IKEv2          April 2006
+
+
+   A special case is where the notification is sent in an Informational
+   exchange, and the lifetime is zero.  In that case, the original
+   responder SHOULD allow a reasonable time for the repeated
+   authentication to occur.
+
+   The AUTH_LIFETIME notification MUST be protected and MAY be sent by
+   the original Responder at any time.  If the policy changes, the
+   original Responder MAY send it again in a new Informational.
+
+   The new Initial exchange is not altered.  The initiator SHOULD delete
+   the old IKE SA within a reasonable time of the new Auth exchange.
+
+3.  AUTH_LIFETIME Notification
+
+   The AUTH_LIFETIME message is a notification payload formatted 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        !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !  Protocol ID  !   SPI Size    !      Notify Message Type      !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                           Lifetime                            !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      o  Payload Length is 12.
+      o  Protocol ID (1 octet) MUST be 0.
+      o  SPI size is 0 (SPI is in message header).
+      o  Notify Message type is 16403 by IANA.
+      o  Lifetime is the amount of time (in seconds) left before the
+         peer should repeat the Initial exchange.  A zero value
+         signifies that the Initial exchange should begin immediately.
+         It is usually not reasonable to set this value to less than 300
+         (5 minutes) since that is too cumbersome for a user.
+         It is also usually not reasonable to set this value to more
+         than 86400 (1 day) as that would negate the security benefit of
+         repeating the authentication.
+
+4.  Interoperability with Non-Supporting IKEv2 Implementations
+
+   IKEv2 implementations that do not support the AUTH_LIFETIME
+   notification will ignore it and will not repeat the authentication.
+   In that case the original Responder will send a Delete notification
+   for the IKE SA in an Informational exchange.  Such implementations
+   may be configured manually to repeat the authentication periodically.
+
+
+
+
+Nir                           Experimental                      [Page 3]
+
+RFC 4478            Repeated Authentication in IKEv2          April 2006
+
+
+   Non-supporting Responders are not a problem because they will simply
+   not send these notifications.  In that case, there is no requirement
+   that the original Initiator re-authenticate.
+
+5.  Security Considerations
+
+   The AUTH_LIFETIME notification sent by the Responder does not
+   override any security policy on the Initiator.  In particular, the
+   Initiator may have a different policy regarding re-authentication,
+   requiring more frequent re-authentication.  Such an Initiator can
+   repeat the authentication earlier then is required by the
+   notification.
+
+   An Initiator MAY set reasonable limits on the amount of time in the
+   AUTH_LIFETIME notification.  For example, an authentication lifetime
+   of less than 300 seconds from SA initiation may be considered
+   unreasonable.
+
+6.  IANA Considerations
+
+   The IANA has assigned a notification payload type for the
+   AUTH_LIFETIME notifications from the IKEv2 Notify Message Types
+   registry.
+
+7.  Normative References
+
+   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+              4306, December 2005.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+Author's Address
+
+   Yoav Nir
+   Check Point Software Technologies
+
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir                           Experimental                      [Page 4]
+
+RFC 4478            Repeated Authentication in IKEv2          April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   [email protected].
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Nir                           Experimental                      [Page 5]
+