draft-ietf-dhc-sedhcpv6-06.txt   draft-ietf-dhc-sedhcpv6-07.txt 
DHC Working Group S. Jiang, Ed. DHC Working Group S. Jiang, Ed.
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track S. Shen Intended status: Standards Track S. Shen
Expires: August 22, 2015 CNNIC Expires: September 24, 2015 CNNIC
D. Zhang D. Zhang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
T. Jinmei T. Jinmei
Infoblox Inc. Infoblox Inc.
February 18, 2015 March 23, 2015
Secure DHCPv6 Secure DHCPv6
draft-ietf-dhc-sedhcpv6-06 draft-ietf-dhc-sedhcpv6-07
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCPv6 servers to pass configuration parameters. It offers DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not being secured, DHCPv6 is configuration flexibility. If not being secured, DHCPv6 is
vulnerable to various attacks, particularly spoofing attacks. This vulnerable to various attacks, particularly spoofing attacks. This
document analyzes the security issues of DHCPv6 and specifies a document analyzes the security issues of DHCPv6 and specifies a
Secure DHCPv6 mechanism for communications between DHCPv6 clients and Secure DHCPv6 mechanism for communications between DHCPv6 clients and
DHCPv6 servers. This document provides a DHCPv6 client/server DHCPv6 servers. This document provides a DHCPv6 client/server
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 August 22, 2015. This Internet-Draft will expire on September 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language and Terminology . . . . . . . . . . . . 3 2. Requirements Language and Terminology . . . . . . . . . . . . 3
3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 4 3. Security Overview of DHCPv6 . . . . . . . . . . . . . . . . . 4
4. Overview of Secure DHCPv6 Mechanism with Public Key . . . . . 4 4. Overview of Secure DHCPv6 Mechanism with Public Key . . . . . 4
4.1. New Components . . . . . . . . . . . . . . . . . . . . . 5 4.1. New Components . . . . . . . . . . . . . . . . . . . . . 6
4.2. Support for Algorithm Agility . . . . . . . . . . . . . . 6 4.2. Support for Algorithm Agility . . . . . . . . . . . . . . 6
4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 7 5. Extensions for Secure DHCPv6 . . . . . . . . . . . . . . . . 8
5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 7 5.1. Public Key Option . . . . . . . . . . . . . . . . . . . . 8
5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8 5.2. Certificate Option . . . . . . . . . . . . . . . . . . . 8
5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9 5.3. Signature Option . . . . . . . . . . . . . . . . . . . . 9
5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 10 5.4. Timestamp Option . . . . . . . . . . . . . . . . . . . . 10
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 11
6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 11 6. Processing Rules and Behaviors . . . . . . . . . . . . . . . 11
6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 11 6.1. Processing Rules of Sender . . . . . . . . . . . . . . . 11
6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13 6.2. Processing Rules of Recipient . . . . . . . . . . . . . . 13
6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 15 6.3. Processing Rules of Relay Agent . . . . . . . . . . . . . 15
6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15 6.4. Timestamp Check . . . . . . . . . . . . . . . . . . . . . 15
7. Deployment Consideration . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Authentication on a client . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.2. Authentication on a server . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]) The Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315])
enables DHCPv6 servers to pass configuration parameters and offers enables DHCPv6 servers to pass configuration parameters and offers
configuration flexibility. If not being secured, DHCPv6 is configuration flexibility. If not being secured, DHCPv6 is
vulnerable to various attacks, particularly spoofing attacks. vulnerable to various attacks, particularly spoofing attacks.
This document analyzes the security issues of DHCPv6 in details. This document analyzes the security issues of DHCPv6 in details.
This document provides mechanisms for improving the security of This document provides mechanisms for improving the security of
skipping to change at page 3, line 34 skipping to change at page 3, line 34
Note: this secure mechanism in this document does not protect the Note: this secure mechanism in this document does not protect the
relay-relevant options, either added by a relay agent toward a server relay-relevant options, either added by a relay agent toward a server
or added by a server toward a relay agent, because they are only or added by a server toward a relay agent, because they are only
transported within operator networks and considered less vulnerable. transported within operator networks and considered less vulnerable.
Communication between a server and a relay agent, and communications Communication between a server and a relay agent, and communications
between relay agents, may be secured through the use of IPsec, as between relay agents, may be secured through the use of IPsec, as
described in section 21.1 in [RFC3315]. described in section 21.1 in [RFC3315].
The security mechanisms specified in this document is based on The security mechanisms specified in this document is based on
sender's public/private key pairs or certificates with associated sender's public/private key pairs or certificates with associated
private keys. The reason for such design and deployment private keys. It also integrates message signatures for the
consideration are discussed in Section 7. It also integrates message integrity and timestamps for anti-replay. The sender authentication
signatures for the integrity and timestamps for anti-replay. The procedure using certificates defined in this document depends on
sender authentication procedure using certificates defined in this deployed Public Key Infrastructure (PKI, [RFC5280]). However, the
document depends on deployed Public Key Infrastructure (PKI, deployment of PKI is out of the scope of this document.
[RFC5280]). However, the deployment of PKI is out of the scope.
Secure DHCPv6 is applicable in environments where physical security Secure DHCPv6 is applicable in environments where physical security
on the link is not assured (such as over wireless) and attacks on on the link is not assured (such as over wireless) and attacks on
DHCPv6 are a concern. DHCPv6 are a concern.
2. Requirements Language and Terminology 2. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
skipping to change at page 5, line 32 skipping to change at page 5, line 29
message only if the validation is successful. The end-to-end message only if the validation is successful. The end-to-end
security protection can be bidirectional, covering messages from security protection can be bidirectional, covering messages from
servers to clients and from clients to servers. Additionally, the servers to clients and from clients to servers. Additionally, the
optional timestamp mechanism provides anti-replay protection. optional timestamp mechanism provides anti-replay protection.
A trust relationship for a public key can be the result either of a A trust relationship for a public key can be the result either of a
Trust-on-first-use (TOFU) policy, or a list of trusted keys Trust-on-first-use (TOFU) policy, or a list of trusted keys
configured on the recipient. configured on the recipient.
A trust relationship for a certificate could also be treated either A trust relationship for a certificate could also be treated either
as Trust-on-first-use or configured in a list of trusted certificate as TOFU or configured in a list of trusted certificate authorities,
authorities, depending on the application. Such applications are out depending on the application.
of scope for this document.
TOFU can be used by a client to authenticate a server and its
messages. It can be deployed without establishing a trust
relationship between the client and the server. Unlike the
Reconfigure Key Authentication Protocol defined in [RFC3315], it can
also be used for other DHCPv6 messages than Reconfigure, and the same
single key can be used for all clients since the server does not send
a secret in plain text on the wire. Overall this will provide a
reasonable balance of easy deployment and moderate level of security,
as long as the risk of the attack window on the first use is
acceptable.
TOFU can also be used by a server to protect an existing DHCPv6
session with a particular client by preventing a malicious client
from hijacking the session. In this case the server does not even
have to store the client's public key or certificate after the
session; it only has to remember the public key during that
particular session and check if it can verify received messages with
that key. This type of authentication can be deployed without a pre-
established trust relationship.
If authentication has to be provided from the initial use, the Secure
DHCPv6 mechanism needs some infrastructure such as PKI so the
recipient of a public key or certificate can verify it securely. It
is currently a subject of further study how such an infrastructure
can be integrated to DHCPv6 in a way it makes the deployment easier.
Secure DHCPv6 messages are commonly large. One example is normal Secure DHCPv6 messages are commonly large. One example is normal
DHCPv6 message length plus a 1 KB for a X.509 certificate and DHCPv6 message length plus a 1 KB for a X.509 certificate and
signature and 256 Byte for a signature. IPv6 fragments [RFC2460] are signature and 256 Byte for a signature. IPv6 fragments [RFC2460] are
highly possible. In practise, the total length would be various in a highly possible. In practise, the total length would be various in a
large range. Hence, deployment of Secure DHCPv6 should also consider large range. Hence, deployment of Secure DHCPv6 should also consider
the issues of IP fragment, PMTU, etc. Also, if there are firewalls the issues of IP fragment, PMTU, etc. Also, if there are firewalls
between secure DHCPv6 clients and secure DHCPv6 servers, it is between secure DHCPv6 clients and secure DHCPv6 servers, it is
RECOMMENDED that the firewalls are configured to pass ICMP Packet Too RECOMMENDED that the firewalls are configured to pass ICMP Packet Too
Big messages [RFC4443]. Big messages [RFC4443].
skipping to change at page 14, line 15 skipping to change at page 14, line 15
procedure in the future. A certificate that finds a match in the procedure in the future. A certificate that finds a match in the
local trust certificate list is treated as verified. local trust certificate list is treated as verified.
If a Public Key option is provided, the recipient SHOULD validate it If a Public Key option is provided, the recipient SHOULD validate it
by finding a matching public key from the local trust public key by finding a matching public key from the local trust public key
list, which is pre-configured or recorded from previous list, which is pre-configured or recorded from previous
communications (TOFU). A local trust public key list is a data table communications (TOFU). A local trust public key list is a data table
maintained by the recipient. It stores public keys from all maintained by the recipient. It stores public keys from all
trustworthy senders. trustworthy senders.
When the local policy of the recipient allows the use of TOFU, if a
Public Key option is provided but it is not found in the local trust
public key list, the recipient MAY accept the public key. The
recipient will normally store the key in the local list for
subsequent DHCPv6 sessions, but it may not necessarily have to do so
depending on the purpose of the authentication (see the case of
authenticating a client with TOFU described in Section 4).
The message that fails authentication check MUST be dropped. In such The message that fails authentication check MUST be dropped. In such
failure, the DHCPv6 server SHOULD reply an AuthenticationFail error failure, the DHCPv6 server SHOULD reply an AuthenticationFail error
status code, defined in Section 5.5, back to the client. status code, defined in Section 5.5, back to the client.
The recipient MAY choose to further process messages from a sender The recipient MAY choose to further process messages from a sender
when there is no matched public key. By recording the public key, when there is no matched public key. By recording the public key,
when the first time it is seen, the recipient can make a Trust On when the first time it is seen, the recipient can make a Trust On
First Use that the sender is trustworthy. The circumstances under First Use that the sender is trustworthy. The circumstances under
which this might be done are out of scope for this document. which this might be done are out of scope for this document.
skipping to change at page 17, line 5 skipping to change at page 17, line 12
timestamp per sender will become full. In this case, the node MUST timestamp per sender will become full. In this case, the node MUST
remove some entries from the cache or refuse some new requested remove some entries from the cache or refuse some new requested
entries. The specific policy as to which entries are preferred over entries. The specific policy as to which entries are preferred over
others is left as an implementation decision. others is left as an implementation decision.
An implementation MAY statefully record the latest timestamps from An implementation MAY statefully record the latest timestamps from
senders. In such implementation, the timestamps MUST be strictly senders. In such implementation, the timestamps MUST be strictly
monotonously increasing. This is reasonable given that DHCPv6 monotonously increasing. This is reasonable given that DHCPv6
messages are rarely misordered. messages are rarely misordered.
7. Deployment Consideration 7. Security Considerations
This document defines two directions of authentication:
authentication based on client's public key certificate and
authentication based on leap of faith to server's public key.
7.1. Authentication on a client
For clients, DHCPv6 authentication generally means verifying whether
the sender of DHCPv6 messages is a legal DHCPv6 server and verifying
whether the message has been modified during transmission. Because
the client may have to validate the authentication in the condition
of without connectivity wider than link-local, authentication with
certificates may not always be feasible. So, this document only
sticks on Leaf of Faith mode, to make sure the client talks to the
same previous server.
Message integrity is provided. But there is a chance for the client
to incorrectly trust a malicious server at the beginning of the first
session with the server (and therefore keep trusting it thereafter).
But the leap of faith mechanim guarantees the subsequent messages are
sent by the same previous server, and therefore narrows the attack
scope. This may make sense if the network can be reasonably
considered secure and requesting pre-configuration is deemed to be
infeasible. A small home network would be an example of such cases.
For environments that are neither controlled nor really trustworthy,
such as a network in a cafeteria, while the leap of faith mode, i.e.,
silently trusting the server at the first time, would be too
insecure. But some middle ground might be justified, such as
requiring human intervention at the point of the leap of faith.
7.2. Authentication on a server
As for authentication on a server, there are several different
scenarios to consider, each of which has different applicability
issues. If the server allows the leap of faith mode, any malicious
user can pretend to be a new legitimate client. While the server can
always be considered to have connectivity to validate certificate, it
is feasible to check client certificates.
Network administrators may wish to constrain the allocation of
addresses to authorized hosts to avoid denial of service attacks in
"hostile" environments where the network medium is not physically
secured, such as wireless networks or college residence halls. A
server may have to selectively serve a specific client or deny
specific clients depending on the identity of the client in a
controlled environment, like a corporate intranet. But the support
from skilled staff or administrator may be required to set up the
clients.
8. Security Considerations
This document provides new security features to the DHCPv6 protocol. This document provides new security features to the DHCPv6 protocol.
Using public key based security mechanism and its verification Using public key based security mechanism and its verification
mechanism in DHCPv6 message exchanging provides the authentication mechanism in DHCPv6 message exchanging provides the authentication
and data integrity protection. Timestamp mechanism provides anti- and data integrity protection. Timestamp mechanism provides anti-
replay function. replay function.
The Secure DHCPv6 mechanism is based on the pre-condition that the The Secure DHCPv6 mechanism is based on the pre-condition that the
recipient knows the public key of the sender or the sender's public recipient knows the public key of the sender or the sender's public
skipping to change at page 19, line 25 skipping to change at page 18, line 30
window of vulnerability. To protect against these attacks, it is window of vulnerability. To protect against these attacks, it is
recommended that Secure DHCPv6 nodes keep independently maintained recommended that Secure DHCPv6 nodes keep independently maintained
clocks or apply suitable security measures for the time clocks or apply suitable security measures for the time
synchronization protocols. synchronization protocols.
One more consideration is that this protocol does reveal additional One more consideration is that this protocol does reveal additional
client information in their certificate. It means less privacy. In client information in their certificate. It means less privacy. In
current practice, the client privacy and the client authentication current practice, the client privacy and the client authentication
are mutually exclusive. are mutually exclusive.
9. IANA Considerations 8. IANA Considerations
This document defines four new DHCPv6 [RFC3315] options. The IANA is This document defines four new DHCPv6 [RFC3315] options. The IANA is
requested to assign values for these four options from the DHCPv6 requested to assign values for these four options from the DHCPv6
Option Codes table of the DHCPv6 Parameters registry maintained in Option Codes table of the DHCPv6 Parameters registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters. The four options http://www.iana.org/assignments/dhcpv6-parameters. The four options
are: are:
The Public Key Option (TBA1), described in Section 5.1. The Public Key Option (TBA1), described in Section 5.1.
The Certificate Option (TBA2), described in Section 5.2. The Certificate Option (TBA2), described in Section 5.2.
skipping to change at page 20, line 33 skipping to change at page 19, line 38
defined in Section 5.5, in the DHCPv6 Parameters registry maintained defined in Section 5.5, in the DHCPv6 Parameters registry maintained
in http://www.iana.org/assignments/dhcpv6-parameters: in http://www.iana.org/assignments/dhcpv6-parameters:
Code | Name | Reference Code | Name | Reference
---------+-----------------------+-------------- ---------+-----------------------+--------------
TBD5 | AlgorithmNotSupported | this document TBD5 | AlgorithmNotSupported | this document
TBD6 | AuthenticationFail | this document TBD6 | AuthenticationFail | this document
TBD7 | TimestampFail | this document TBD7 | TimestampFail | this document
TBD8 | SignatureFail | this document TBD8 | SignatureFail | this document
10. Acknowledgements 9. Acknowledgements
The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms, The authors would like to thank Bernie Volz, Ted Lemon, Ralph Droms,
Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher, Jari Arkko, Sean Turner, Stephen Kent, Thomas Huth, David Schumacher,
Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan, Francis Dupont, Tomek Mrugalski, Gang Chen, Qi Sun, Suresh Krishnan,
Fred Templin and other members of the IETF DHC working group for Fred Templin, Robert Elz and other members of the IETF DHC working
their valuable comments. group for their valuable comments.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
11. Change log [RFC Editor: Please remove] 10. Change log [RFC Editor: Please remove]
draft-ietf-dhc-sedhcpv6-07: removed the deployment consideration
section; instead, described more straightforward use cases with TOFU
in the overview section, and clarified how the public keys would be
stored at the recipient when TOFU is used. The overview section also
clarified the integration of PKI or other similar infrastructure is
an open issue.
draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients draft-ietf-dhc-sedhcpv6-06: remove the limitation that only clients
use PKI- certificates and only servers use public keys. The new text use PKI- certificates and only servers use public keys. The new text
would allow clients use public keys and servers use PKI-certificates would allow clients use public keys and servers use PKI-certificates
draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that draft-ietf-dhc-sedhcpv6-05: addressed comments from mail list that
responsed to the second WGLC. responsed to the second WGLC.
draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list. draft-ietf-dhc-sedhcpv6-04: addressed comments from mail list.
Making timestamp an independent and optional option. Reduce the Making timestamp an independent and optional option. Reduce the
skipping to change at page 21, line 42 skipping to change at page 21, line 5
Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/ Ted Lemon, Bernie Volz, Ralph Droms. Separated Public Key/
Certificate option into two options. Refined many detailed Certificate option into two options. Refined many detailed
processes. 2013-10-08. processes. 2013-10-08.
draft-jiang-dhc-sedhcpv6-00: original version, this draft is a draft-jiang-dhc-sedhcpv6-00: original version, this draft is a
replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and replacement of draft-ietf-dhc-secure-dhcpv6, which reached IESG and
dead because of consideration regarding to CGA. The authors followed dead because of consideration regarding to CGA. The authors followed
the suggestion from IESG making a general public key based mechanism. the suggestion from IESG making a general public key based mechanism.
2013-06-29. 2013-06-29.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
skipping to change at page 22, line 43 skipping to change at page 22, line 5
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, October 2014.
12.2. Informative References 11.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, November 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
 End of changes. 18 change blocks. 
87 lines changed or deleted 72 lines changed or added

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