draft-ietf-ospf-security-extension-manual-keying-06.txt   draft-ietf-ospf-security-extension-manual-keying-07.txt 
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track S. Hartman Intended status: Standards Track S. Hartman
Expires: May 29, 2014 Painless Security Expires: October 10, 2014 Painless Security
D. Zhang D. Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
A. Lindem A. Lindem
Ericsson Ericsson
November 25, 2013 April 8, 2014
Security Extension for OSPFv2 when using Manual Key Management Security Extension for OSPFv2 when using Manual Key Management
draft-ietf-ospf-security-extension-manual-keying-06 draft-ietf-ospf-security-extension-manual-keying-07
Abstract Abstract
The current OSPFv2 cryptographic authentication mechanism as defined The current OSPFv2 cryptographic authentication mechanism as defined
in RFC 2328 and RFC 5709 is vulnerable to both inter-session and in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
intra-session replay attacks when using manual keying. Additionally, intra-session replay attacks when using manual keying. Additionally,
the existing cryptographic authentication schemes do not cover the IP the existing cryptographic authentication mechanism does not cover
header. This omission can be exploited to carry out various types of the IP header. This omission can be exploited to carry out various
attacks. types of attacks.
This draft proposes changes to the authentication sequence number This draft proposes changes to the authentication sequence number
mechanism that will protect OSPFv2 from both inter-session and intra- mechanism that will protect OSPFv2 from both inter-session and intra-
session replay attacks when using manual keys for securing OSPFv2 session replay attacks when using manual keys for securing OSPFv2
protocol packets. Additionally, we also describe some changes in the protocol packets. Additionally, we also describe some changes in the
cryptographic hash computation so that we eliminate most attacks that cryptographic hash computation that will eliminate attacks resulting
result from OSPFv2 not protecting the IP header. from OSPFv2 not protecting the IP header.
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 29, 2014. This Internet-Draft will expire on October 10, 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 3, line 10 skipping to change at page 3, line 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The OSPFv2 cryptographic authentication mechanism as described in The OSPFv2 cryptographic authentication mechanism as described in
[RFC2328] uses per-packet sequence numbers to provide protection [RFC2328] uses per-packet sequence numbers to provide protection
against replay attacks. The sequence numbers increase monotonically against replay attacks. The sequence numbers increase monotonically
so that attempts to replay the stale packets can be thwarted. The so that attempts to replay stale packets can be thwarted. The
sequence number values are maintained as a part of adjacency states. sequence number values are maintained as a part of neighbor adjacency
Therefore, if an adjacency is taken down, the associated sequence state. Therefore, if an adjacency is taken down, the associated
numbers get reinitialized and the neighbors start all over again. sequence numbers get reinitialized and neighbor adjacency formation
Additionally, the cryptographic authentication mechanism does not starts over again. Additionally, the cryptographic authentication
specify how to deal with the rollover of a sequence number when its mechanism does not specify how to deal with the rollover of a
value wraps. These omissions can be taken advantage of by attackers sequence number when its value wraps. These omissions can be
to implement various replay attacks ([RFC6039]). In order to address exploited by attackers to implement various replay attacks
these issues, we propose extensions to the authentication sequence ([RFC6039]). In order to address these issues, we propose extensions
number mechanism. to the authentication sequence number mechanism.
The cryptographic authentication as described in [RFC2328] and later The cryptographic authentication as described in [RFC2328] and later
updated in [RFC5709] does not include the IP header. This also can updated in [RFC5709] does not include the IP header. This omission
be exploited to launch several attacks as the source address in the can be exploited to launch several attacks as the source address in
IP header is no longer protected. The OSPF specification, for the IP header is not protected. The OSPF specification, for
broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires
implementations to look at the source address in the IP header to implementations to use the source address in the IP header to
determine the neighbor from which the packet was received. Changing determine the neighbor from which the packet was received. Changing
the IP source address of a packet that confuses the receiver and can the IP source address of a packet to a conflicting IP address can be
be exploited to produce a number of denial of service attacks exploited to produce a number of denial of service attacks [RFC6039].
[RFC6039]. If the packet is interpreted as coming from a different If the packet is interpreted as coming from a different neighbor, the
neighbor, the sequence number received from the neighbor may be received sequence number state for that neighbor may be incorrectly
updated. This may disrupt communication with the legitimate updated. This attack may disrupt communication with a legitimate
neighbor. Hello packets may be reflected to cause a neighbor to neighbor. Hello packets may be reflected to cause a neighbor to
appear to have one-way communication. Additionally, Database appear to have one-way communication. Additionally, Database
Description packets may be reflected in cases where the per-packet Description packets may be reflected in cases where the per-packet
sequence numbers are sufficiently divergent in order to disrupt an sequence numbers are sufficiently divergent in order to disrupt an
adjacency [RFC6863]. This is referred to as the IP layer issue in adjacency [RFC6863]. This is referred to as the IP layer issue in
[RFC6862]. [RFC6862].
[RFC2328] states that implementations MUST offer keyed MD5 [RFC2328] states that implementations MUST offer keyed MD5
authentication. It is likely that this will be deprecated in favor authentication. It is likely that this will be deprecated in favor
of the stronger algorithms described in [RFC5709] and required in of the stronger algorithms described in [RFC5709] and required in
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Additionally, the 64-bit sequence number is moved to the first 64- Additionally, the 64-bit sequence number is moved to the first 64-
bits following the OSPFv2 packet and is protected by the bits following the OSPFv2 packet and is protected by the
authentication digest. These additional 64 bits or 8 octets are authentication digest. These additional 64 bits or 8 octets are
included in the IP header length but not the OSPF header packet included in the IP header length but not the OSPF header packet
length. length.
0 1 2 3 0 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length | | Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID | | Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType | | Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len | | 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | | Key ID |
skipping to change at page 7, line 13 skipping to change at page 7, line 13
time. time.
o The key must be valid for the desired security algorithm. o The key must be valid for the desired security algorithm.
In the remainder of this section, additional requirements for keys In the remainder of this section, additional requirements for keys
are enumerated for different scenarios. are enumerated for different scenarios.
4.1. Key Selection for Unicast OSPF Packet Transmission 4.1. Key Selection for Unicast OSPF Packet Transmission
Assume that a router R1 tries to send a unicast OSPF packet from its Assume that a router R1 tries to send a unicast OSPF packet from its
interface I1 to the interface R2 of a remote router R2 using security interface I1 to the interface I2 of a remote router R2 using security
protocol P via interface I at time T. First, consider the protocol P via interface I at time T. First, consider the
circumstances where R1 and R2 are not connected with a virtual link. circumstances where R1 and R2 are not connected with a virtual link.
R1 then needs to select a long long-lived symmetric key from its key R1 then needs to select a long long-lived symmetric key from its key
table. Because the key should be shared by the by both R1 and R2 to table. Because the key should be shared by both R1 and R2 to protect
protect the communication between I1 and I2, the key should satisfy the communication between I1 and I2, the key should satisfy the
the following requirements: following requirements:
o The Peers field is unused. OSPF authentication is interface o The Peers field is unused. OSPF authentication is interface
based. based.
o The Interfaces field includes the local IP address of the o The Interfaces field includes the local IP address of the
interface for numbered interfaces or the MIB-II [RFC1213], ifIndex interface for numbered interfaces or the MIB-II [RFC1213] ifIndex
for unnumbered interfaces. for unnumbered interfaces.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interface, the key with the most recent o If multiple keys match the Interfaces field, the key with the most
SendLifetimeStart time will be selected. This will facilitate recent SendLifetimeStart time will be selected. This will
graceful key rollover. facilitate graceful key rollover.
o The Key ID field in the OSPFv2 header (refer to figure 1) will be o The Key ID field in the OSPFv2 header (refer to figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
When R1 and R2 are connected to a virtual link, the interfaces field When R1 and R2 are connected to a virtual link, the Interfaces field
must identify the virtual endpoint rather than the virtual link. must identify the virtual endpoint rather than the virtual link.
Since there may be virtual links to the same router, the transit area Since there may be virtual links to the same router, the transit area
ID must be part of the identifier. Hence, the key should satisfy the ID must be part of the identifier. Hence, the key should satisfy the
following requirements: following requirements:
o The Peers field is unused. OSPF authentication is interface o The Peers field is unused. OSPF authentication is interface
based. based.
o The Interfaces field includes both the virtual endpoint's OSPF o The Interfaces field includes both the virtual endpoint's OSPF
router ID and the transit area ID for the virtual link. router ID and the transit area ID for the virtual link.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interface, the key with the most recent o If multiple keys match the Interfaces field, the key with the most
SendLifetimeStart time will be selected. This will facilitate recent SendLifetimeStart time will be selected. This will
graceful key rollover. facilitate graceful key rollover.
o The Key ID field in the OSPFv2 header (refer to figure 1) will be o The Key ID field in the OSPFv2 header (refer to figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
4.2. Key Selection for Multicast OSPF Packet Transmission 4.2. Key Selection for Multicast OSPF Packet Transmission
If a router R1 sends an OSPF packet from its interface I1 to a If a router R1 sends an OSPF packet from its interface I1 to a
multicast address (e.g., AllSPFRouters, AllDRouters), it needs to multicast address (i.e., AllSPFRouters or AllDRouters), it needs to
select a key according to the following requirements: select a key according to the following requirements:
o The Peers field is unused. OSPF authentication is interface o The Peers field is unused. OSPF authentication is interface
based. based.
o The Interfaces field includes the local IP address of the o The Interfaces field includes the local IP address of the
interface for numbered interfaces or the MIB-II [RFC1213], ifIndex interface for numbered interfaces or the MIB-II [RFC1213] ifIndex
for unnumbered interfaces. for unnumbered interfaces.
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o If multiple keys match the Interface, the key with the most recent o If multiple keys match the Interfaces field, the key with the most
SendLifetimeStart time will be selected. This will facilitate recent SendLifetimeStart time will be selected. This will
graceful key rollover. facilitate graceful key rollover.
o The Key ID field in the OSPFv2 header (refer to figure 1) will be o The Key ID field in the OSPFv2 header (refer to figure 1) will be
set to the selected key's LocalKeyName. set to the selected key's LocalKeyName.
4.3. Key Selection for OSPF Packet Reception 4.3. Key Selection for OSPF Packet Reception
When Cryptographic Authentication is used, the ID of the When Cryptographic Authentication is used, the ID of the
authentication key is included in the authentication field of the authentication key is included in the authentication field of the
OSPF packet header. Using this key ID, it is relatively easy for a OSPF packet header. Using this Key ID, it is straight forward for a
receiver to locate the key. The simple requirements are: receiver to locate the corresponding key. The simple requirements
are:
o The interface on which the key was received is associated with the o The interface on which the key was received is associated with the
key's interface. key's interface.
o The Key ID obtained from the OSPFv2 packet header corresponds to o The Key ID obtained from the OSPFv2 packet header corresponds to
the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the
LocalKeyName and PeerKeyName for OSPFv2 keys will be identical. LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.
Hence, the Key ID will be used to select the correct local key. Hence, the Key ID will be used to select the correct local key.
o The Direction field is either "in" or "both". o The Direction field is either "in" or "both".
5. Securing the IP header 5. Securing the IP header
This document updates the definition of Apad which is currently a This document updates the definition of the Apad constant, as it is
constant defined in [RFC5709] to the source address from the IP defined in [RFC5709], to include the IP source address from the IP
header of the OSPFv2 protocol packet. The overall cryptographic header of the OSPFv2 protocol packet. The overall cryptographic
authentication process defined in [RFC5709] remains unchanged. To authentication process defined in [RFC5709] remains unchanged. To
reduce the potential for confusion, this section minimizes the reduce the potential for confusion, this section minimizes the
repetition of text from RFC 5709 and is incorporated here by repetition of text from RFC 5709 [RFC5709]. The changes are:
reference [RFC5709].
RFC 5709, Section 3.3, describes how the cryptographic authentication RFC 5709, Section 3.3, describes how the cryptographic authentication
must be computed. It requires OSPFv2 packet's Authentication Trailer must be computed. It requires the OSPFv2 packet's Authentication
(which is the appendage described in RFC 2328, Section D.4.3, Page Trailer (which is the appendage described in RFC 2328, Section D.4.3,
233, items (6)(a) and (6)(d)) to be filled with the value Apad where Page 233, items (6)(a) and (6)(d)) to be filled with the value Apad.
Apad is a hexadecimal constant value 0x878FE1F3 repeated (L/4) times, Apad is a hexadecimal constant with the value 0x878FE1F3 repeated
where L is the length of the hash being used and is measured in (L/4) times, where L is the length of the hash being used and is
octets rather than bits. measured in octets rather than bits.
Routers at the sending side must initialize Apad to a value of the OSPF routers sending OSPF packets must initialize Apad to the value
source address that would be used when sending out the OSPFv2 packet, of the IP source address that would be used when sending an OSPFv2
repeated L/4 times, where L is the length of the hash, measured in packet, repeated L/4 times, where L is the length of the hash,
octets. The basic idea is to incorporate the source address from the measured in octets. The basic idea is to incorporate the IP source
IP header in the cryptographic authentication computation so that any address from the IP header in the cryptographic authentication
change of IP source address in a replayed packet can be detected. computation so that any change of IP source address in a replayed
packet can be detected.
At the receiving end, implementations MUST initialize Apad as the When an OSPF packet is received, implementations MUST initialize Apad
source address from IP Header of the incoming OSPFv2 packet, repeated as the IP source address from the IP Header of the incoming OSPFv2
L/4 times, instead of the constant that's currently defined in packet, repeated L/4 times, instead of the constant that's currently
[RFC5709]. Besides changing the value of Apad, this document does defined in [RFC5709]. Besides changing the value of Apad, this
not introduce any other changes to the authentication mechanism document does not introduce any other changes to the authentication
described in [RFC5709]. This would prevent all attacks where a rogue mechanism described in [RFC5709]. This would prevent all attacks
OSPF router changes the IP source address of an OSPFv2 packet and where a rogue OSPF router changes the IP source address of an OSPFv2
replays it on the same multi-access interface or another interface packet and replays it on the same multi-access interface or another
since the IP source address is now protected and modification would interface since the IP source address is now included in the
result in the OSPFv2 packet being dropped due to an authentication cryptographic hash computation and modification would result in the
failure. OSPFv2 packet being dropped due to an authentication failure.
6. Mitigating Cross-Protocol Attacks 6. Mitigating Cross-Protocol Attacks
In order to prevent cross protocol replay attacks for protocols In order to prevent cross-protocol replay attacks for protocols
sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID
is appended to the authentication key prior to use. Refer to IANA is appended to the authentication key prior to use. Refer to IANA
Considerations (Section 8). Considerations (Section 8).
[RFC5709], Section 3.3 describes the mechanism to prepare the key [RFC5709], Section 3.3 describes the mechanism to prepare the key
used in the hash computation. This document updates the sub section used in the hash computation. This document updates the sub section
"PREPARATION OF KEY" as follows: "PREPARATION OF KEY" as follows:
The OSPFv2 Cryptographic Protocol ID is appended to the The OSPFv2 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific Authentication Authentication Key (K) yielding a Protocol-Specific Authentication
skipping to change at page 10, line 39 skipping to change at page 10, line 39
7. Security Considerations 7. Security Considerations
This document rectifies the manual key management procedure that This document rectifies the manual key management procedure that
currently exists within OSPFv2, as part of the Phase 1 of the KARP currently exists within OSPFv2, as part of the Phase 1 of the KARP
Working Group. Therefore, only the OSPFv2 manual key management Working Group. Therefore, only the OSPFv2 manual key management
mechanism is considered. Any solution that takes advantage of the mechanism is considered. Any solution that takes advantage of the
automatic key management mechanism is beyond the scope of this automatic key management mechanism is beyond the scope of this
document. document.
The proposed sequence number extension offers most of the benefits of The proposed sequence number extension offers most of the benefits of
more complicated mechanisms involving challenges. There are, more complicated mechanisms without their attendant challenges.
however, a couple drawbacks to this approach. First, it requires the There are, however, a couple drawbacks to this approach. First, it
OSPF implementation to be able to save its boot count in non-volatile requires the OSPF implementation to be able to save its boot count in
storage. If the non-volatile storage is ever repaired or upgraded non-volatile storage. If the non-volatile storage is ever repaired
such that the contents are lost or the OSPFv2 router is replaced, the or upgraded such that the contents are lost or the OSPFv2 router is
keys MUST be changed to prevent replay attacks. replaced, the authentication keys MUST be changed to prevent replay
attacks.
Second, if a router is taken out of service completely (either Second, if a router is taken out of service completely (either
intentionally or due to a persistent failure), the potential exists intentionally or due to a persistent failure), the potential exists
for reestablishment of an OSPFv2 adjacency by replaying the entire for reestablishment of an OSPFv2 adjacency by replaying the entire
OSPFv2 session establishment. This scenario is however, extremely OSPFv2 session establishment. However, this scenario is extremely
unlikely, since it would imply an identical OSPFv2 adjacency unlikely, since it would imply an identical OSPFv2 adjacency
formation packet exchange. Without adjacency formation, the replay formation packet exchange. Without adjacency formation, the replay
of OSPFv2 hello packets alone for an OSPFv2 router that has been of OSPFv2 hello packets alone for an OSPFv2 router that has been
taken out of service should not result in any serious attack as the taken out of service should not result in any serious attack as the
only consequence is superfluous processing. Of course, this attack only consequence is superfluous processing. Of course, this attack
could also be thwarted by changing the relevant manual keys. could also be thwarted by changing the relevant manual keys.
This document also provides a solution to prevent certain denial of This document also provides a solution to prevent certain denial of
service attacks that can be launched by changing the source address service attacks that can be launched by changing the source address
in the IP header of an OSPFv2 protocol packet. in the IP header of an OSPFv2 protocol packet.
skipping to change at page 11, line 49 skipping to change at page 12, line 4
9.2. Informative References 9.2. Informative References
[FIPS-198] [FIPS-198]
US National Institute of Standards & Technology, "The US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198 , March 2002. 198 , March 2002.
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-07 (work in progress), draft-ietf-karp-crypto-key-table-10 (work in progress),
March 2013. December 2013.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II", for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991. STD 17, RFC 1213, March 1991.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
 End of changes. 31 change blocks. 
86 lines changed or deleted 88 lines changed or added

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