< draft-polk-saag-rtg-auth-keytable-01.txt		draft-polk-saag-rtg-auth-keytable-02.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: 29 April 2010 26 October 2009		Expires: 7 June 2010 4 December 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-01.txt		draft-polk-saag-rtg-auth-keytable-02.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 5, line 5 ¶		skipping to change at page 4, line 51 ¶
	| |		| |
	| |		| |
	+-------+-------+ V		+-------+-------+ V
	| | +-------+-------+		| | +-------+-------+
	| Initiate | | |		| Initiate | | |
	| Session | |Authentication |		| Session | |Authentication |
	| with Peer | | Mechanism |		| with Peer | | Mechanism |
	| | | |		| | | |
	+---------------+ +---------------+		+---------------+ +---------------+
	Figure 3 illustrates how an entity that receives a session generates		Figure 2. Session Initiation
	the necessary long-lived cryptographic keys to verify data when a
	protected session is requested. As step one in the initiation		Figure 3 illustrates how the long-lived cryptographic keys are
	process, the receiver extracts the keyID for the long-term keyID from		accessed and employed when an entity receives a request establish a
	the received data. The receiver then requests the specified long-		protected session with a peer. As step one in the session
	term key from the table. The long-term key is provided as an input,		establishment process, the receiver extracts the keyID for the long-
	along with session-specific information (e.g., ports or initial		term keyID from the received data. The receiver then requests the
	counters), to a key derivation function. The result is session-		specified long-term key from the table. The long-term key is provided
	specific key material which is used to verify the cryptographic		as an input, along with session-specific information (e.g., ports or
	authentication information.		initial counters), to a key derivation function. The result is
			session-specific key material which is used to verify the
			cryptographic authentication information.
	+-------------------------+		+-------------------------+
	| |		| |
	| Long-Lived |		| Long-Lived |
	| Crypto Keys |		| Crypto Keys |
	| |		| |
	+-+---------------------+-+		+-+---------------------+-+
	^ |		^ |
	| |		| |
	| V		| V
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	^ |		^ |
	| |		| |
	| V		| V
	+-------+-------+ +-------+-------+		+-------+-------+ +-------+-------+
	| | | |		| | | |
	| Receive Data | |Authentication |		| Receive Data | |Authentication |
	| From Peer | | Mechanism |		| From Peer | | Mechanism |
	| | | |		| | | |
	+---------------+ +---------------+		+---------------+ +---------------+
			Figure 3. Session Acceptance
	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		In practice, the mapping process need only be applied to the
	LocalKeyID, whose value must be unique in the context of the		LocalKeyID, whose value must be unique in the context of the
	database, as defined in [KEYTAB]. Uniqueness is not required for the		database, as defined in [KEYTAB]. Uniqueness is not required for the
	PeerKeyID, so mapping is generally restricted to truncation. Mapping		PeerKeyID, so mapping is generally restricted to truncation. Mapping
	would only be needed to expand PererKeyID's value beyond 16 bits.		would only be needed to expand PeerKeyID's value beyond 16 bits.
	4.1 Selected Range Reservation		4.1 Selected Range Reservation
	Where a protocol uses 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. Without identifier mapping these protocols would share		identifiers. Without identifier mapping these protocols would share
	the space {0x0000 through 0x00ff} which would limit the pair of		the space {0x0000 through 0x00ff} which would limit the pair of
	protocols to 256 keys in total. By reserving the ranges {0x7f00		protocols to 256 keys in total. By reserving the ranges {0x7f00
	through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2		through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2
	respectively permits each protocol to use the full 256 key		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 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
	Each protocol can also maintain a simple mapping table with two		Each protocol can also maintain a simple mapping table with two
	fields: the l6 bit index and the protocol specific value		fields: the 16 bit index and the protocol specific value:
	KEYTAB index (16 bits) | Protocol specific index (8 bits)		KEYTAB index (16 bits) | Protocol specific index (8 bits)
	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
	skipping to change at page 7, line 14 ¶		skipping to change at page 7, line 14 ¶
	5.1 Setup		5.1 Setup
	The owners of Xp and Yp determine a need for authenticated		The owners of Xp and Yp determine a need for authenticated
	communication using TCP-AO. They decide to use AES-CMAC-128 for		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		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		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-		will be available from 12/31/2010 through 12/31/2011. Through an out-
	of-band channel, the administrators establish the shared secret:		of-band channel, the administrators establish the shared secret:
	0x0123456789ABCDEF0123456789ABCDEF		0x0123456789ABCDEF0123456789ABCDEF
	Peer Xp selects the first available TCP-AO identifier in the reserved		Peer Xp selects the first available TCP-AO identifier in the reserved
	range, which is 0x7f05 and maps to an eight bit identifier 0x05.		range, which is 0x7f05 and maps to an eight-bit identifier 0x05.
	Peer Yp selects the next available TCP-AO identifier, 0x12, and the		Peer Yp selects the next available TCP-AO identifier, 0x12, and the
	next available LocalKeyID, which is 0x0107. Peer Yp also adds an		next available LocalKeyID, which is 0x0107. Peer Yp also adds an
	entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP-		entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP-
	AO identifier, as shown in Figure 5:		AO identifier, as shown in Figure 5:
	LocalKeyID TCP-AO identifier		LocalKeyID TCP-AO identifier
	--------------------------------		--------------------------------
	0x001a | 0x01		0x001a | 0x01
	0x004d | 0x02		0x004d | 0x02
	... ...		... ...
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	(6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO,		(6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO,
	PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned.		PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned.
	(7) Yp performs the session key derivation using the mechanism		(7) Yp performs the session key derivation using the mechanism
	specified for the TCP-AO protocol in [ao-crypto].		specified for the TCP-AO protocol in [ao-crypto].
	(8) Yp verifies the MACs for the incoming traffic using the derived		(8) Yp verifies the MACs for the incoming traffic using the derived
	key.		key.
	5.3 Protocol Operation: Yp Initiates a Connection		5.3 Protocol Operation: Yp Initiates a Connection
	Where Peer Yp establishes the connection, the same process is		Where Peer Yp establishes the connection, the same process is
	followed, except that range mapping process from step (2) is replaced		followed, except that the range mapping process from step (2) is
	by a table lookup.		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 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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-08.txt, October
			2009.
	[ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, &		[ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, &
	Implementation Requirments for TCP Authentication		Implementation Requirments for TCP Authentication
	Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt,		Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt,
	July 2009.		July 2009.
	Author's Addresses		Author's Addresses
	Tim Polk		Tim Polk
	National Institute of Standards and Technology		National Institute of Standards and Technology
End of changes. 10 change blocks.
	20 lines changed or deleted		24 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/