< draft-polk-saag-rtg-auth-keytable-00.txt   draft-polk-saag-rtg-auth-keytable-01.txt >
INTERNET DRAFT T. Polk INTERNET DRAFT T. Polk
Intended Status: Informational NIST Intended Status: Informational NIST
R. Housley R. Housley
Vigil Security Vigil Security
Expires: 19 April 2010 19 October 2009 Expires: 29 April 2010 26 October 2009
Routing Authentication Using A Database of Long-Lived Cryptographic Keys Routing Authentication Using A Database of Long-Lived Cryptographic Keys
draft-polk-saag-rtg-auth-keytable-00.txt draft-polk-saag-rtg-auth-keytable-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
established between two peers for pair-wise communications, or established between two peers for pair-wise communications, or
between groups of peers for multicast traffic. between groups of peers for multicast traffic.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Architecture and Design . . . . . . . . . . . . . . . . . . . . . 2 2 Architecture and Design . . . . . . . . . . . . . . . . . . . . . 2
3 Pair-wise Application . . . . . . . . . . . . . . . . . . . . . . 3 3 Pair-wise Application . . . . . . . . . . . . . . . . . . . . . . 3
4 Identifier Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 4 Identifier Mapping . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Selected Range Reservation . . . . . . . . . . . . . . . . . 5 4.1 Selected Range Reservation . . . . . . . . . . . . . . . . . 6
4.2 Protocol Specific Mapping Tables . . . . . . . . . . . . . . 6 4.2 Protocol Specific Mapping Tables . . . . . . . . . . . . . . 6
5 Worked Example: TCP-AO . . . . . . . . . . . . . . . . . . . . . 6 5 Worked Example: TCP-AO . . . . . . . . . . . . . . . . . . . . . 6
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Protocol Operation: Xp Initiates a Connection . . . . . . . 8
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Protocol Operation: Yp Initiates a Connection . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7.2 Informative References . . . . . . . . . . . . . . . . . . 7 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 11
1 Introduction 1 Introduction
This document describes the application of a database of long-lived This document describes the application of a database of long-lived
cryptographic keys, as defined in [KEYTAB], to establish session- cryptographic keys, as defined in [KEYTAB], to establish session-
specific cryptographic keys to provide authentication services in specific cryptographic keys to provide authentication services in
routing protocols. Keys may be established between two peers for routing protocols. Keys may be established between two peers for
pair-wise communications, or between groups of peers for multicast pair-wise communications, or between groups of peers for multicast
traffic. traffic.
skipping to change at page 5, line 47 skipping to change at page 5, line 49
+---------------+ +---------------+ +---------------+ +---------------+
4 Identifier Mapping 4 Identifier Mapping
[KEYTAB] specifies a 16-bit identifier, but protocols already exist [KEYTAB] specifies a 16-bit identifier, but protocols already exist
with key identifiers of various sizes. Where the identifiers are of with key identifiers of various sizes. Where the identifiers are of
different sizes, an extra mapping step may be required. Note that different sizes, an extra mapping step may be required. Note that
mapping mechanisms are local - that is, different mapping mechanisms mapping mechanisms are local - that is, different mapping mechanisms
could be employed on different peers. could be employed on different peers.
In practice, the mapping process need only be applied to the
LocalKeyID, whose value must be unique in the context of the
database, as defined in [KEYTAB]. Uniqueness is not required for the
PeerKeyID, so mapping is generally restricted to truncation. Mapping
would only be needed to expand PererKeyID's value beyond 16 bits.
4.1 Selected Range Reservation 4.1 Selected Range Reservation
Where a protocol sues an index of less than 16 bits, a selected range Where a protocol uses an index of less than 16 bits, a selected range
of the local index space can be reserved for a particular protocol. of the local index space can be reserved for a particular protocol.
For example, consider two protocols P1 and P2 that each use 8 bit key For example, consider two protocols P1 and P2 that each use 8 bit key
identifiers. Sharing the space {0x0000 through 0x00ff} would limit identifiers. Without identifier mapping these protocols would share
the pair pair of protocols to 256 keys in total. By reserving the the space {0x0000 through 0x00ff} which would limit the pair of
ranges {0xff00 through 0xffff} and {0xfe00 through 0xfeff} for P1 and protocols to 256 keys in total. By reserving the ranges {0x7f00
P2 respectively permits each protocol to use the full 256 key through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2
respectively permits each protocol to use the full 256 key
identifiers and establishes an unambiguous mapping for the protocol identifiers and establishes an unambiguous mapping for the protocol
key identifiers and local table identifiers. key identifiers and local table identifiers.
When an initiator selects a key from the set in the table, the given When an initiator selects a key from the set in the table, the given
key identifier needs to be masked or shifted to the on-the-wire key identifier needs to be masked or shifted to the on-the-wire
range. Before requesting a specific key, the receiver would use a range. Before requesting a specific key, the receiver would use a
shim layer would need to map the on-the-wire identifier into the shim layer would need to map the on-the-wire identifier into the
reserved range. reserved range.
4.2 Protocol Specific Mapping Tables 4.2 Protocol Specific Mapping Tables
skipping to change at page 6, line 36 skipping to change at page 6, line 44
In this case, the host system would maintain separate mapping tables In this case, the host system would maintain separate mapping tables
for protocols P1 and P2. for protocols P1 and P2.
5 Worked Example: TCP-AO 5 Worked Example: TCP-AO
This section describes the way a TCP-AO implementation could use the This section describes the way a TCP-AO implementation could use the
database. [tcpao] TCP-AO protocol is an example where the key database. [tcpao] TCP-AO protocol is an example where the key
identifier is limited to 8 bits, so an identifier mapping is needed. identifier is limited to 8 bits, so an identifier mapping is needed.
We will assume two peers Xp and Yp. Xp employs the range reservation We will assume two peers Xp and Yp. Xp employs the range reservation
method for mapping and has reserved the range {0xff00 ... 0xffff} method for mapping and has reserved the range {0x7f00 ... 0x7fff} for
mapping to {0x00 ... 0xff}. Yp employs a protocol specific mapping LocalKeyIDs for TCP-AO, mapping to {0x00 ... 0xff}. Yp employs a
table. protocol specific mapping table in its TCP-AO implementation.
<<Completed Example TBD>> The following subsections describe how peers Xp and Yp make use of
the database of long-lived cryptographic keys when Xp and Yp
respectively initiate a session. (Note: Rollover to new sessions
keys during a session is described in [tcpao].)
5.1 Setup
The owners of Xp and Yp determine a need for authenticated
communication using TCP-AO. They decide to use AES-CMAC-128 for
authentication, so a 128 bit key is needed. They decide to use the
same key for both directions (inbound and outbound), and that the key
will be available from 12/31/2010 through 12/31/2011. Through an out-
of-band channel, the administrators establish the shared secret:
0x0123456789ABCDEF0123456789ABCDEF
Peer Xp selects the first available TCP-AO identifier in the reserved
range, which is 0x7f05 and maps to an eight bit identifier 0x05.
Peer Yp selects the next available TCP-AO identifier, 0x12, and the
next available LocalKeyID, which is 0x0107. Peer Yp also adds an
entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP-
AO identifier, as shown in Figure 5:
LocalKeyID TCP-AO identifier
--------------------------------
0x001a | 0x01
0x004d | 0x02
... ...
0x0107 | 0x12
Figure 5. Protocol Specific KeyID Mapping Table for TCP-AO
After exchanging the TCP-AO identifiers, the peers have sufficient
information to establish their [KEYTAB] entries. Peer Xp's [KEYTAB]
entry is shown as Figure 6:
LocalKeyID 0x7f05
PeerKeyID 0x0012
KDFInputs none
AlgID AES-CMAC-128
Key 0x0123456789ABCDEF0123456789ABCDEF
Direction both
NotBefore 12/31/2010
NotAfter 12/31/2011
Peers yp.example.com
Protocol TCP-AO
Figure 6. Key Table Entry on Xp
Peer Yp's [KEYTAB] entry is shown as Figure 6:
LocalKeyID 0x0107
PeerKeyID 0x0005
KDFInputs none
AlgID AES-CMAC-128
Key 0x0123456789ABCDEF0123456789ABCDEF
Direction both
NotBefore 12/31/2010
NotAfter 12/31/2011
Peers xp.example.com
Protocol TCP-AO
Figure 7. Key Table Entry on Yp
5.2 Protocol Operation: Xp Initiates a Connection
Peer Xp wishes to initiate a connection with Peer Yp.
(1) Xp performs a key lookup for {Peer=Yp, Protocol=TCP-AO}, and the
entry with LocalKeyID 0x7f05 is returned.
(2) The LocalKeyID 0x7f05 is range mapped by Xp to the TCP-AO
identifier 0x05.
(3) Xp performs the session key derivation using the mechanism
specified for the TCP-AO protocol in [ao-crypto].
(4) Xp generates the AES-CMAC-128 MACs for the outgoing traffic using
the derived key, and asserts the key identifier 0x05 in the packets.
(5) Yp receives a protected packet from Xp, and extracts the key
identifier 0x05.
(6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO,
PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned.
(7) Yp performs the session key derivation using the mechanism
specified for the TCP-AO protocol in [ao-crypto].
(8) Yp verifies the MACs for the incoming traffic using the derived
key.
5.3 Protocol Operation: Yp Initiates a Connection
Where Peer Yp establishes the connection, the same process is
followed, except that range mapping process from step (2) is replaced
by a table lookup.
6 Security Considerations 6 Security Considerations
<Security considerations text> <Security considerations text>
6 IANA Considerations 6 IANA Considerations
This document requires no actions by IANA. This document requires no actions by IANA.
7 References 7 References
skipping to change at page 7, line 29 skipping to change at page 9, line 29
[KEYTAB] R. Housley and Polk, T. "Database of Long-Lived [KEYTAB] R. Housley and Polk, T. "Database of Long-Lived
Cryptographic Keys", draft-housley-saag-crypto-key-table- Cryptographic Keys", draft-housley-saag-crypto-key-table-
00.txt, September 2009. 00.txt, September 2009.
7.2 Informative References 7.2 Informative References
[tcpao] J. Touch, Mankin A., and Bonica R. "The TCP Authentication [tcpao] J. Touch, Mankin A., and Bonica R. "The TCP Authentication
Option", draft-ietf-tcpm-tcp-auth-opt-05.txt, July 2009. Option", draft-ietf-tcpm-tcp-auth-opt-05.txt, July 2009.
[ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, &
Implementation Requirments for TCP Authentication
Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt,
July 2009.
Author's Addresses Author's Addresses
Tim Polk Tim Polk
National Institute of Standards and Technology National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930 100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930 Gaithersburg, MD 20899-8930
USA USA
EMail: tim.polk@nist.gov EMail: tim.polk@nist.gov
Russell Housley Russell Housley
 End of changes. 10 change blocks. 
19 lines changed or deleted 120 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/