< draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt   draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt >
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 5996 (if approved) P. Hoffman Obsoletes: 5996 (if approved) P. Hoffman
Intended status: Standards Track VPN Consortium Intended status: Standards Track VPN Consortium
Expires: May 17, 2014 Y. Nir Expires: October 27, 2014 Y. Nir
Check Point Check Point
P. Eronen P. Eronen
Independent Independent
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
November 13, 2013 April 25, 2014
Internet Key Exchange Protocol Version 2 (IKEv2) Internet Key Exchange Protocol Version 2 (IKEv2)
draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining Security Associations authentication and establishing and maintaining Security Associations
(SAs). This document replaces and updates RFC 5996, and includes all (SAs). This document obsoletes RFC 5996, and includes all of the
of the errata for it, and it is intended to update IKEv2 to be errata for it, and it is intended to update IKEv2 to be Internet
Internet Standard. Standard.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2014. This Internet-Draft will expire on October 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 27 skipping to change at page 4, line 27
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 118 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 118
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 119 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 119
5. Security Considerations . . . . . . . . . . . . . . . . . . . 121 5. Security Considerations . . . . . . . . . . . . . . . . . . . 121
5.1. Traffic Selector Authorization . . . . . . . . . . . . . 124 5.1. Traffic Selector Authorization . . . . . . . . . . . . . 124
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.1. Normative References . . . . . . . . . . . . . . . . . . 127 8.1. Normative References . . . . . . . . . . . . . . . . . . 127
8.2. Informative References . . . . . . . . . . . . . . . . . 128 8.2. Informative References . . . . . . . . . . . . . . . . . 128
Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 132 Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 132
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 134 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 133
B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 134 B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 134
B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 134 B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 134
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 134 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 134
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 135 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 135
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 136 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 136
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 137 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 137
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 138 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 138
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 138 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 138
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 138 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 138
skipping to change at page 22, line 32 skipping to change at page 22, line 32
In Section 3.15.3, a pointer to a new document that is related to In Section 3.15.3, a pointer to a new document that is related to
configuration of IPv6 addresses was added. configuration of IPv6 addresses was added.
Appendix C was expanded and clarified. Appendix C was expanded and clarified.
1.8. Differences between RFC 5996 and This Document 1.8. Differences between RFC 5996 and This Document
Fixed section 3.6 and 3.10 as specified in the RFC5996 errata 2707 Fixed section 3.6 and 3.10 as specified in the RFC5996 errata 2707
and 3036. and 3036.
Removed Raw RSA Public keys. There is new work ongoing to replace Deprecated Raw RSA Public keys. There is new work ongoing to replace
that with more generic format for generic raw public keys. that with more generic format for generic raw public keys.
Added reference to the RFC6989 when using non Sophie-Germain Diffie- Added reference to the RFC6989 when using non Sophie-Germain Diffie-
Hellman groups, or when reusing Diffie-Hellman Exponentials. Hellman groups, or when reusing Diffie-Hellman Exponentials.
Added reference to the RFC4945 in the Identification Payloads Added reference to the RFC4945 in the Identification Payloads
section. section.
Added IANA Considerations section note about removing the Raw RSA Added IANA Considerations section note about deprecating the Raw RSA
Key, and removed the old contents which was already done during Key, and removed the old contents which was already done during
RFC5996 processing. Added note that IANA should update IKEv2 RFC5996 processing. Added note that IANA should update IKEv2
registry to point to this document instead of RFC5996. registry to point to this document instead of RFC5996.
Clarified that the intended status of this document is Internet Clarified that the intended status of this document is Internet
Standard both in abstract and Introduction section. Standard both in abstract and Introduction section.
Added name Last Substruc for the Proposal and Transform Substructure Added name Last Substruc for the Proposal and Transform Substructure
header for the 0 (last) or 2/3 (more) field. header for the 0 (last) or 2/3 (more) field.
skipping to change at page 72, line 10 skipping to change at page 72, line 10
repeats of that message including a cookie). repeats of that message including a cookie).
o Next Payload (1 octet) - Indicates the type of payload that o Next Payload (1 octet) - Indicates the type of payload that
immediately follows the header. The format and value of each immediately follows the header. The format and value of each
payload are defined below. payload are defined below.
o Major Version (4 bits) - Indicates the major version of the IKE o Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the major version to 2. Implementations based on MUST set the major version to 2. Implementations based on
previous versions of IKE and ISAKMP MUST set the major version to previous versions of IKE and ISAKMP MUST set the major version to
1. Implementations based on this version of IKE MUST reject or 1. Implementations based on this document's version (version 2)
ignore messages containing a version number greater than 2 with an of IKE MUST reject or ignore messages containing a version number
INVALID_MAJOR_VERSION notification message as described in Section greater than 2 with an INVALID_MAJOR_VERSION notification message
2.5. as described in Section 2.5.
o Minor Version (4 bits) - Indicates the minor version of the IKE o Minor Version (4 bits) - Indicates the minor version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the minor version to 0. They MUST ignore the minor MUST set the minor version to 0. They MUST ignore the minor
version number of received messages. version number of received messages.
o Exchange Type (1 octet) - Indicates the type of exchange being o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message in an used. This constrains the payloads sent in each message in an
exchange. The values in the following table are only current as exchange. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
skipping to change at page 94, line 5 skipping to change at page 94, line 5
crl [1] CertificateList } crl [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END END
Implementations MUST be capable of being configured to send and Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication, accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the and also MUST be capable of being configured to send and accept the
two Hash and URL formats (with HTTP URLs). If multiple certificates two Hash and URL formats (with HTTP URLs). If multiple certificates
are sent, the first certificate MUST contain the public key used to are sent, the first certificate MUST contain the public key
sign the AUTH payload. The other certificates may be sent in any associated with the private key used to sign the AUTH payload. The
order. other certificates may be sent in any order.
Implementations MUST support the HTTP [HTTP] method for hash-and-URL Implementations MUST support the HTTP [HTTP] method for hash-and-URL
lookup. The behavior of other URL methods [URLS] is not currently lookup. The behavior of other URL methods [URLS] is not currently
specified, and such methods SHOULD NOT be used in the absence of a specified, and such methods SHOULD NOT be used in the absence of a
document specifying them. document specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request payload, denoted CERTREQ in this document, The Certificate Request payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
skipping to change at page 99, line 51 skipping to change at page 99, line 51
non-cryptographic parameters. non-cryptographic parameters.
More information on error handling can be found in Section 2.21. More information on error handling can be found in Section 2.21.
The values in the following table are only current as of the The values in the following table are only current as of the
publication date of RFC 4306, plus two error types added in this publication date of RFC 4306, plus two error types added in this
document. Other values may have been added since then or will be document. Other values may have been added since then or will be
added after the publication of this document. Readers should refer added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values. to [IKEV2IANA] for the latest values.
NOTIFY messages: error types Value NOTIFY messages: error types Value
------------------------------------------------------------------- -------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1 UNSUPPORTED_CRITICAL_PAYLOAD 1
See Section 2.5. See Section 2.5.
INVALID_IKE_SPI 4 INVALID_IKE_SPI 4
See Section 2.21. See Section 2.21.
INVALID_MAJOR_VERSION 5 INVALID_MAJOR_VERSION 5
See Section 2.5. See Section 2.5.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a DoS request was rejected for policy reasons. To avoid a DoS
attack using forged messages, this status may only be attack using forged messages, this status may only be
returned for and in an encrypted packet if the Message ID and returned for and in an encrypted packet if the Message ID and
cryptographic checksum were valid. To avoid leaking information cryptographic checksum were valid. To avoid leaking information
to someone probing a node, this status MUST be sent in response to someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types. to any error not covered by one of the other status types.
To aid debugging, more detailed error information should be To aid debugging, more detailed error information should be
written to a console or log. written to a console or log.
INVALID_MESSAGE_ID 9 INVALID_MESSAGE_ID 9
See Section 2.3. See Section 2.3.
INVALID_SPI 11 INVALID_SPI 11
See Section 1.5. See Section 1.5.
NO_PROPOSAL_CHOSEN 14 NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals (including but not sent in any case where the offered proposals (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify, limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder. IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7. cannot be created for some other reason. See also Section 2.7.
INVALID_KE_PAYLOAD 17 INVALID_KE_PAYLOAD 17
See Sections 1.2 and 1.3. See Sections 1.2 and 1.3.
AUTHENTICATION_FAILED 24 AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when, for some reason, Sent in the response to an IKE_AUTH message when, for some
the authentication failed. There is no associated data. See also reason, the authentication failed. There is no associated
Section 2.21.2. data. See also Section 2.21.2.
SINGLE_PAIR_REQUIRED 34 SINGLE_PAIR_REQUIRED 34
See Section 2.9. See Section 2.9.
NO_ADDITIONAL_SAS 35 NO_ADDITIONAL_SAS 35
See Section 1.3. See Section 1.3.
INTERNAL_ADDRESS_FAILURE 36 INTERNAL_ADDRESS_FAILURE 36
See Section 3.15.4. See Section 3.15.4.
FAILED_CP_REQUIRED 37 FAILED_CP_REQUIRED 37
See Section 2.19. See Section 2.19.
TS_UNACCEPTABLE 38 TS_UNACCEPTABLE 38
See Section 2.9. See Section 2.9.
INVALID_SELECTORS 39 INVALID_SELECTORS 39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives MAY be sent in an IKE INFORMATIONAL exchange when a node receives
an ESP or AH packet whose selectors do not match those of the SA an ESP or AH packet whose selectors do not match those of the SA
on which it was delivered (and that caused the packet to be on which it was delivered (and that caused the packet to be
dropped). The Notification Data contains the start of the dropped). The Notification Data contains the start of the
offending packet (as in ICMP messages) and the SPI field of the offending packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the Child SA. notification is set to match the SPI of the Child SA.
TEMPORARY_FAILURE 43 TEMPORARY_FAILURE 43
See section 2.25. See section 2.25.
CHILD_SA_NOT_FOUND 44 CHILD_SA_NOT_FOUND 44
See section 2.25. See section 2.25.
NOTIFY messages: status types Value NOTIFY messages: status types Value
------------------------------------------------------------------- -------------------------------------------------------------------
INITIAL_CONTACT 16384 INITIAL_CONTACT 16384
See Section 2.4. See Section 2.4.
SET_WINDOW_SIZE 16385 SET_WINDOW_SIZE 16385
See Section 2.3. See Section 2.3.
ADDITIONAL_TS_POSSIBLE 16386 ADDITIONAL_TS_POSSIBLE 16386
skipping to change at page 125, line 40 skipping to change at page 125, line 40
configuration in most circumstances. See [H2HIPSEC] for an extensive configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host discussion about this issue, and the limitations of host-to-host
IPsec in general. IPsec in general.
6. IANA Considerations 6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already [IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so they are not registered those types and values in [IKEV2IANA], so they are not
listed here again. listed here again.
One item has been removed from the IKEv2 Certificate Encodings table: One item has been deprecated from the IKEv2 Certificate Encodings
"Raw RSA Key". table: "Raw RSA Key".
IANA has updated all references to RFC 5996 to point to this IANA has updated all references to RFC 5996 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
Many individuals in the IPsecME Working Group were very helpful in Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others. reviewing the clarifications suggested by others.
skipping to change at page 129, line 37 skipping to change at page 129, line 37
[DOSUDPPROT] [DOSUDPPROT]
C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
for UDP-based protocols", ACM Conference on Computer and for UDP-based protocols", ACM Conference on Computer and
Communications Security, October 2003. Communications Security, October 2003.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", Department of Commerce, "Digital Signature Standard",
Draft FIPS 186-3, June 2008. Draft FIPS 186-3, June 2008.
[EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, [EAI] Yang, A., Steele, S., and N. Freed, "Internationalized
September 2008. Email Headers", RFC 6532, February 2012.
[EAP-IANA] [EAP-IANA]
"Extensible Authentication Protocol (EAP) Registry: Method "Extensible Authentication Protocol (EAP) Registry: Method
Types", <http://www.iana.org>. Types", <http://www.iana.org>.
[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication Protocols", November 2002, Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>. <http://eprint.iacr.org/2002/163>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
skipping to change at page 131, line 12 skipping to change at page 131, line 12
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[MAILFORMAT] [MAILFORMAT]
Resnick, P., Ed., "Internet Message Format", RFC 5322, Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 6275, July 2011.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[MODES] National Institute of Standards and Technology, U.S. [MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001. Modes of Operation", SP 800-38A, 2001.
skipping to change at page 132, line 20 skipping to change at page 132, line 20
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2 Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, July 2013. (IKEv2)", RFC 6989, July 2013.
[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. [ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010. Compression over IPsec", RFC 5857, May 2010.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978.
[SHA] National Institute of Standards and Technology, U.S. [SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", Department of Commerce, "Secure Hash Standard",
FIPS 180-3, October 2008. FIPS 180-3, October 2008.
[SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Advances in Cryptography - CRYPTO 2003 Protocols", Advances in Cryptography - CRYPTO 2003
Proceedings LNCS 2729, 2003, <http:// Proceedings LNCS 2729, 2003, <http://
www.informatik.uni-trier.de/~ley/db/conf/crypto/ www.informatik.uni-trier.de/~ley/db/conf/crypto/
crypto2003.html>. crypto2003.html>.
 End of changes. 32 change blocks. 
85 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/