ims-volte-vowifi
/
strongswan
9
0
Fork 0
Code Pull Requests Releases Activity

added often used RFCs and drafts

This commit is contained in:
Martin Willi 2006-09-27 14:10:32 +00:00
parent 112ad7c383
commit f91513e333
9 changed files with 29363 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/charon/doc/Todo-list.txt
View File

@ -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

3250
src/charon/doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt Normal file
View File

File diff suppressed because it is too large Load Diff

6720
src/charon/doc/standards/draft-hoffman-ikev2-1-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

6776
src/charon/doc/standards/draft-hoffman-ikev2bis-00.txt Normal file
View File

File diff suppressed because it is too large Load Diff

785
src/charon/doc/standards/draft-myers-ikev2-ocsp-03.txt Normal file
View File

@ -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: mmyers@fastq.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
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
ietf-ipr@ietf.org.
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]

5659
src/charon/doc/standards/rfc4301.txt Normal file
View File

File diff suppressed because it is too large Load Diff

5547
src/charon/doc/standards/rfc4306.txt Normal file
View File

File diff suppressed because it is too large Load Diff

339
src/charon/doc/standards/rfc4307.txt Normal file
View File

@ -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: jis@mit.edu
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-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schiller Standards Track [Page 6]

283
src/charon/doc/standards/rfc4478.txt Normal file
View File

@ -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: ynir@checkpoint.com
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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nir Experimental [Page 5]