< draft-tschofenig-hiprg-hip-srtp-00.txt		draft-tschofenig-hiprg-hip-srtp-01.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: January 12, 2006 F. Muenz		Expires: April 26, 2006 F. Muenz
	FH-Landshut		FH-Landshut
	M. Shanmugam		M. Shanmugam
	TUHH		TUHH
	July 11, 2005		October 23, 2005
	Using SRTP transport format with HIP		Using SRTP transport format with HIP
	draft-tschofenig-hiprg-hip-srtp-00.txt		draft-tschofenig-hiprg-hip-srtp-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 12, 2006.		This Internet-Draft will expire on April 26, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The Host Identity Protocol is a signaling protocol which adds another		The Host Identity Protocol (HIP) is a signaling protocol which adds a
	layer to the Internet model and (optionally) establishes IPsec ESP		new layer between the traditional Transport and Network layer. HIP
	SAs to protect subsequent data traffic. HIP is an end-to-end		is an end-to-end authentication and key exchange protocol, which
	authentication and key exchange protocol, which supports security and		supports security and mobility in a commendable manner. The HIP base
	mobility in a commendable manner. This draft explains a Secure Real		specification is genralized and purported to support different key
	Time Protocol (SRTP) based mechanism for transmission of user data		exchange mechanisms in order to provide confidentiality protection
	packets, to be used with the Host Identity Protocol (HIP).		for the subsequent data traffic. In some cases it might not be
			desirable to establish IPsec security associations for protection of
			media traffic. This draft explains how keying material and
			parameters for usage with the Secure Real Time Protocol (SRTP) can be
			established using HIP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1 Base Exchange . . . . . . . . . . . . . . . . . . . . . . 7		4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2 Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. SRTP in HIP . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3 Packet Format . . . . . . . . . . . . . . . . . . . . . . 10		4.1.1. Setting up an SRTP Association . . . . . . . . . . . . 7
	4. Key management . . . . . . . . . . . . . . . . . . . . . . . . 13		4.1.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1 Normative References . . . . . . . . . . . . . . . . . . . 17		5.2. Pseudo-random byte-string (RAND) . . . . . . . . . . . . . 9
	6.2 Informative References . . . . . . . . . . . . . . . . . . 17		5.3. Security Policies (SP) . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18		5.4. Master Key Identifier (MKI) . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . 19		6. Key management . . . . . . . . . . . . . . . . . . . . . . . . 13
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
			8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
			9.2. Informative References . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way to		The Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way
	separate the dual role of IP (end point identifier and locator) by		to separate the dual role of IP (end point identifier and locator) by
	adding a new layer between the traditional Network and Transport		adding a new layer between the traditional Network and Transport
	layer . This separation helps the end host to achieve mobility,		layer. This separation helps the end host to achieve mobility,
	furthermore, HIP provides better security features (like end-to-end		furthermore, HIP provides better security features (like end-to-end
	authentication, confidentiality for the data traffic etc) than other		authentication, confidentiality for the data traffic etc) than other
	multi6 proposals [I-D.ietf-hip-multi6].		multi6 proposals [I-D.ietf-hip-multi6].
	HIP is based on public key cryptography. All HIP hosts have a		HIP is based on public key cryptography. All HIP hosts have a
	public/private key pair. HIP introduces a new name space called Host		public/private key pair. HIP introduces a new name space called Host
	Identity. It is nothing but the public key of an asymmetric key		Identity. It is nothing but the public key of an asymmetric key
	pair. It provides a rapid exchange of host identities (public keys)		pair. It provides a rapid exchange of host identities (public keys)
	between communicating hosts and (optionally) establishes IPsec SAs to		between communicating hosts and (optionally) establishes IPsec SAs to
	protect subsequent data traffic. It is a four-way handshake		protect subsequent data traffic. It is a four-way handshake
	protocol, which supports end-to-end authentication and the data		protocol, which supports end-to-end authentication and the data
	traffic may experience IPsec ESP encapsulation. Since different		traffic may experience IPsec ESP encapsulation.
	sizes for the public key are possible, it uses the Host Identity Tag
	(HIT), which is the hash of the public key, for operational
	representation. The HIP header carries HIT (128 bits long), which is
	similar to IPV6 addresses.
	Transport connections and Security Associations between the		Transport connections and security associations between the
	communicating HIP hosts are bound to the HITs only. IP addresses are		communicating HIP hosts are bound to the HITs and IP addresses are
	used for routing purposes only. Therefore, changes to IP addresses		used for routing purposes only. Therefore, changes to IP addresses
	do not change the connections or associations. So, when any of the		do not change the connections or associations. So, when any of the
	peers move, it uses a readdressing mechanism to update the current		peers move (mobility scenarios), it uses a readdressing mechanism to
	location of the peer, thereby supporting mobility in a seamless		update the current location of the peer, thereby supporting mobility
	manner.		in a seamless manner.
	Session Initiation Protocol (SIP) is an application layer protocol,
	which is capable of establishing modifying and terminating sessions
	between the hosts. The SIP architecture uses URIs to uniquely
	identify (maps) the user agents and has various infrastructure
	components like proxy server, redirect server etc., to achieve
	personal mobility.
	SIP, when combined with RTP, can effectively handle multimedia		The HIP base exchange provides mutual authentication of the hosts,
	applications. SIP can also invite participants to already existing		but does not specify any mechanism for protecting data packets.
	sessions, such as multicast conferences. Media can be added to (and		[I-D.ietf-hip-esp] draft proposes a way to use IPsec ESP format with
	removed from) an existing session. SIP relies on other security		HIP.
	protocols like TLS, IPsec, HTTP Digest mechanisms to protect the SIP
	traffic.
	HIP base exchange [I-D.ietf-hip-base] does not describe any transport		Secure Real Time Protocol (SRTP) is a profile for Real Time Protocol
	formats for user data. This document proposes extensions to HIP by		(RTP), which provides a framework for providing encryption,
	exporting the relevant parameters to support other key management		integrity, message authentication, confidentiality and protection
	scheme, like MIKEY. SRTP proposes MIKEY [RFC3830] as a key		against replay attacks for the real-time data traffic.
	management protocol. We propose to use the same key management
	scheme in HIP. HIP combined with MIKEY alike scheme can be used for
	SRTP as a key management protocol to exchange Master Keys and create
	a Cryptographic Context (SRTP RFC chapter 3.2). HIP has to satisfy
	the requirements of SRTP (SRTP RFC chapter 7/8) for a key management
	protocol and has to support the appropriate cryptographic algorithms
	within its transform parameters.
	HIP base exchange provides a mutual authentication of the hosts, but		SRTP mandates the use of a external key management protocol to
	does not specify any mechanism for protecting data packets for the		exchange keys and cryptographic parameters, which are used to derive
	actual communication. [I-D.ietf-hip-esp] draft proposes a way to use		keys (like cipher suites, random number etc.,). This draft proposes
	IPsec ESP format with HIP. In this document, we specify the use of		a way to exchange the SRTP relevant parameters during the HIP base
	SRTP for protecting user data traffic after the HIP base exchange.		exchange. Besides this, we inherited the key derivation procedure of
			SRTP to show how the keys will be manipulated and maintained for the
			data traffic. Appendix A describes one possible use case to support
			this document.
	SRTP mandates the use of a external key management protocol (like		This document is organized as follows. Section 3 explains the
	MIKEY) to exchange keys and cryptographic parameters, which are used		revised base exchange, Section 4 explains the rekeying scenario,
	to derive keys (like cipher suites, random number etc.,). This draft		Section 5 presents the packet format and Section 6 explains the key
	proposes a way to exchange the SRTP relevant parameters during the		derivation, and future work.
	HIP base exchange. Besides this, we inherited the key derivation
	procedure of SRTP to show how the keys will be manipulated and
	maintained for the data traffic.
	This document explains the compatibility of HIP and SIP together with		This document was developed in the context of investigating the
	the new KEY management scheme. Section 3 explains the revised base		benefits of using HIP for SIP.
	exchange, and Section 4 explains the key derivation and future work.
	2. Terminology		2. 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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This draft used the terminology defined in [I-D.ietf-hip-base] and		This draft uses the terminology defined in [I-D.ietf-hip-base] and
	[RFC3261].		[RFC3261].
	The term MKI refers to Master Key Identifier used in SRTP packets.		The term MKI, an optionl parameter, refers to Master Key Identifier
	It is similar to SPIs in IPsec.		used in SRTP packets.
	3. Message Flow		3. Goal
	This section explains the integration of SIP and HIP. The motivation		The HIP base exchange is used to set up a HIP association between two
	to combine HIP and SIP is defined in [I-D.ietf-hip-sip]. SIP uses		hosts. The base exchange provides two-way host authentication and
	URIs, which bind to an IP address or a host name. When HIP is used,		key material generation, but it does not provide any means for
	SIP headers will make use of HITs instead of IPs i.e, SIP URIs will		protecting data communication between the hosts. In this document,
	be bound to HITs. A HIT is derived from HI (public key), which		we specify the use of SRTP for protecting user data traffic after the
	identify users/hosts and IP addresses. The resolution of IP from HI/		HIP base exchange. Note that we did not consider the key management
	HITs can be done via DNS or other mechanisms. Also, the HI/HITs can		issues in this draft.
	be exchanged using SIP/SDP mechanism as desribed in [I-D.ietf-hip-
	sip].
	Initially the caller sends an INVITE message to its proxy server,		To facilitate the use of SRTP, the HIP base exchange messages require
	assuming that the caller is already connected. Then the caller proxy		some minor additions to the parameters transported. In the R1
	server locates the callee proxy server, possibly by performing a		packet, the responder adds the possible KEYING Parameter before
	particular type of DNS (Domain Name Service) lookup (DNS SRV record).		sending it to the Initiator. The Initiator gets the proposed
	DNS will return the HI/HIT of the callee together with one or more IP		transforms, selects one of those proposed transforms, and adds it to
	addresses of SIP proxies responsible for the callee. After		the I2 packet in the corresponding KEYING Parameter.
	resolution it forwards the message to a callee proxy server and adds
	a new entry in the SIP header (for route record routability). The
	callee proxy receiving the INVITE message consults a location
	database via a location service to resolve the HIT of the callee to
	current IP address. Finally, it forwards the INVITE to the callee.
	There are several ways how to combine SIP messages with HIP base-		In this context, the goal of our proposal is to,
	exchange. SIP and HIP messages could be combined to reduce
	roundtrips or can be used separately.The latter will be explained in
	detail in this section.
	+---------+ +---------+		o define new parameter exchange for the relevant SRTP parameters.
	+------+ |SIP Proxy| |SIP Proxy| +------+
	|Caller| |Caller | |Callee | |Callee|
	+------+ +---------+ +---------+ +------+
	+---INVITE-------->| | |
	| +---INVITE---------->| |
	| | +---INVITE-------->|
	| | |<--OK-------------+
	| |<--OK---------------+ |
	|<--OK-------------+ | |
	+----------------------ACK-------------------------------->|
	+---------+		o define the relevant packets structure and parameters.
	+------+ |HIP RVS | +------+
	|Caller| |Callee | |Callee|
	+------+ +---------+ +------+
	| | |
	+-------------------I1-------------->+-------I1--------->|
	|<------------------R1-----------------------------------+
	+-------------------I2---------------------------------->|
	|<------------------R2-----------------------------------+
	| | |
	|<==================TCP/UDP Session=====================>|
	Figure 1: SIP and HIP Base Exchange		4. The Protocol
	Session establishment works in known ways. First an INVITE is routed		In this section, the protocol for setting up an SRTP association to
	from the caller to the callee using SIP proxies. The callee then		be used with HIP association is described.
	answers with 200 OK and the caller acknowledges with an ACK message
	directly to the callee. However in this scenario, the SDP of the SIP
	signalling traffic will not include any SRTP parameters (transforms),
	which will be decoupled and delegated to HIP. SIP only serves as a
	rendezvous protocol for HIP to exchange end-host IP addresses and
	negotiate HIP as the used end-to-end authentication and key exchange
	protocol.
	3.1 Base Exchange		4.1. SRTP in HIP
	After HIP is chosen there are again two possibilities on how to		4.1.1. Setting up an SRTP Association
	proceed. Firstly HIP base-exchange may run directly between
	communication partners or secondly the callee might be using HIP
	rendezvous server which is shown in figure 1.
	As explained in the previous sections, HIP allows the use of other		Setting up an SRTP Association between hosts using HIP consists of
	key management protocols. Figure 2 explains how the new KEYING		two messages passed between the hosts. The parameters are included
	parameters fit into the HIP base exchange:		in R1 and I2 messages during base exchange.
			Initiator Responder
			I1
			---------------------------------->
			R1: T, KEYING PARAMS
			<----------------------------------
			I2: T, KEYING PARAMS
			---------------------------------->
			R2
			<----------------------------------
			The integration of HIP and SRTP requires some changes, as mentioned
			earlier, in the HIP parameters. The changes are (will be) adding,
			T: The timestamp, used mainly to prevent replay attacks.
			KEYING parameter contains
			RAND: Random/pseudo-random byte-string, RAND(nonce) is used as a
			fresh value for the key generation.
			SP: The security policies for the data security protocol. (eg.
			Algorithms and transforms and PRFs supported by the peers). The
			cipher suites can be negotiated from R1/I2 packet.
			MKI : to identify the Master key and Master salt.
			The R1 message contains the KEYING PARAMS, in which the sending host
			defines the possible Algorithms and transforms, random number and
			optionally MKI it is willing to use for the SRTP association.
			The I2 message contains the response to an KEYING PARAMS received in
			the R1 message. The sender must select one of the proposed
			transforms from the SP parameter in the R1 message and include the
			selected one in the SP parameter in the I2 packet. In addition to
			the transform, the host includes the RAND parameter, containing the
			random value (and optionally MKI) to be used as a salt by the peer
			host. In the R2 message, HIP exchange is finalized.
			4.1.2. Rekeying
			Rekeying can be supported using the UPDATE packet of HIP. The peer
			which wants to rekey should use the UPDATE packet with the
			appropriate parameters. The mechanism is explained below:
	Initiator Responder		Initiator Responder
	I1: ------Trigger exchange--------------------------------->		UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN]
			----------------------------------------------->
			UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN]
			<-----------------------------------------------
			Fig 2:Rekeying mechanism
	R1: <------ puzzle{HI(R),DH(R)}sig(R)------------------------		Figure 2 depicts the rekeying scenario. Here, assume that the
			Initiator wants to rekey after the Initial exchange. It can send the
			rekeying parameters in the Update packet. The same mechanism is
			followed here, the Initiator chooses its Diffie-Hellmann value and
			sends it to the Responder. It may send a new MKI value to identify
			the incoming packet.
	I2: -{Soln,DH(I), KEYING param.,MKI, enc{HI}keymat }sig(I)->		The other parameters are explained in [I-D.ietf-hip-base]. The
			Responder checks the return routability by sending the Update seq
			message containing its Diffie-Hellmann value and relevant parameters
			for the rekeying. After receiving the packet, the Initiator sends
			the ACK thereby both the peers concluding the rekeying procedure and
			now, both of the peers expect to receive the traffic in the new
			keying material.
	R2: <------ { KEYING param.,MKI, HMAC }sig(R) ---------------		5. Parameter and Packet Formats
	Fig 2: Base Exchange		This section explains the relationship between the SRTP and KEYING
			parameter and presents the proposed packet format.
	The Initiator starts the HIP connection by sending the trigger		Master Key - derived from Diffie-Hellmann value
	message. This message is nothing but two IPs and HITs of the
	Initiator and the Responder respectively. The Responder answers with
	the R1 packet, the difference between the actual HIP exchange and the
	proposed mechanism is the removal of the cipher suites, because the
	transforms will be chosen via KEYING parameter. Since we have to
	avoid the state creation, it sends a precomputed packet.
	Context id = <SSRC, destination HIT/address, destination port> This		Master Salt - RAND in the KEYING parameter
	triple SHALL uniquely identiies a cryptographic context (SRTP RFC
	chapter 3.2.3.). This context id together with MKI will be mapped to
	the master key and cipher suites in KEYING management scheme to find
	the session keys to process the packet.
	Any specific transform parameters needed for the SRTP cryptographic		MKI - Master Key Identifier
	context will be exchanged by using SP parameter of KEYING parameter
	in HIP.
	Master Key - derived from Diffie-Hellmann value		Master Key and its length - obtained from Diffie-Hellmann key
			exchange
	Master Salt - RAND in the KEYING parameter		Session keys are derived using Master key, Master salt and SP and the
			details are up to the key managament protocol.
	MKI - Master Key Identifier		As discussed previously, KEYING parameters contains four element:
	Upon receiving it , the Initiator solves the puzzle and sends the I2		5.1. Timestamp
	packet with the Diffie Hellmann value and its KEYING parameter. For
	the explanation of KEYING parameter see above. The Initiator's HI is
	encrypted by the keying material derived from the master key (Diffie
	Hellmann value), so that the responder can also derive the same key
	using the negotiated cipher suites and Diffie Hellmann value to
	decrypt the HI. The key management and key derivation is up to the
	KEY scheme. The whole packet is signed by the Initiator's public
	key.
	The Responder receives the packet verifies the solution, derives the		The timestamp, used mainly to prevent replay attacks. Like in the
	key using the Diffie Hellmann value and the KEYING parameter,		SRTP packet format a 32-bit value is used to store the timestamp.
	decrypts the HI, using the keying material , and verifies the
	Signature. The Responder derives all the encryption and
	authentication keys from the Initiator's master (Diffie Hellmann) and
	salt key (KEYING parameter RAND). The reason for this is that both
	the Initiator and Responder have the same key pairs for providing
	confidentiality for the data traffic.
	Next, the Responder sends its KEYING parameter , the same time stamp,		0 1 2 3
	random no, the selected cipher suites and HMAC of the whole packet,		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
	the key for HMAC is derived from the Master Key. It sends its MKI to		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	identify the incoming packet. The Initiator will check the HMAC and		| Type | Length |
	also the Signature to verify the integrity and authenticity of the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	packet. After this, the HIP association is established and both the		| Timestamp (T) |
	hosts use their respective master key and it derived keys for		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	protecting the traffic. The Master Key is 128 bit long, which can be
	exchanged using the Diffie Hellmann parameter.
	3.2 Rekeying		Fig 4: Timestamp parameter
	Rekeying can be supported using the UPDATE packet of HIP. The peer		Type: 40001 (experimental identifier range)
	which wants to rekey should use the UPDATE packet with the		Length: 4
	appropriate parameters. The mechanism is explained below:		Value: Timestamp
	Initiator Responder		5.2. Pseudo-random byte-string (RAND)
	Update -Update([seq,REA],DH(R),KEYING param., MKI,HMAC)Sig(I) ----->		The RAND or master salt parameter is used as a fresh value for the
			key generation. The RAND parameter is a 112 bit quantity.
	Seq <-Update seq([ack, REA],DH(I),KEYING param.,MKI,HMAC)Sig(R)-		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| |
			| Pseudo-random byte-string (RAND) |
			| |
			| |
			| |
			| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Update ---------------Update ACK( ack, HMAC)Sig(I)----------------->		Fig 5: Pseudo-random byte-string parameter
	ACK
	Fig 3:Rekeying mechanism
	Figure 3 depicts the rekeying scenario. Here, assume that the		Type: 40002 (experimental identifier range)
	Initiator wants to rekey after the Initial exchange. It can send the		Length: 14
	rekeying parameters in the Update packet. The same mechanism is		Value: Pseudo-random byte-string
	followed here, the Initiator chooses its Diffie Hellmann value and
	sends it to the Responder. The key for HMAC has been derived from
	the old Master key. It also sends a new MKI value to identify the
	incoming packet.
	The Responder chooses its Diffie Hellmann value, verifies the HMAC		5.3. Security Policies (SP)
	and Signature. The other parameters are explained in [I-D.ietf-hip-
	base] draft. The Responder checks the return routability by sending
	the Update seq message containing its relevant parameters for the
	rekeying. After receiving the packet, the Initiator sends the ACK
	thereby both the peers concluding the rekeying procedure and now,
	both of the peers expect to receive the traffic in the new keying
	material.
	3.3 Packet Format		The security policies for the data security protocol. (eg. algorithms
			and transforms and PRFs supported by the peers). The cipher suites
			can be negotiated from I2/R2 packet.
	This section explains the packet format for the KEYING parameter in		0 1 2 3
	more detail.		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Security policy parameters ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	KEYING parameter contains		Fig 6: Security policy parameters parameters
	T: The timestamp, used mainly to prevent replay attacks.		Type: 40004 (experimental identifier range)
			Length: variable
			Value: See below
	RAND: Random/pseudo-random byte-string, RAND(nonce) is used as a		The security policy parameters themselves are built up by a set of
	freshness value for the key generation (salts).		Type/Length/Value fields:
	SP: The security policies for the data security protocol. (eg.		0 1 2 3
	Algorithms and transforms and PRFs supported by the peers). The		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
	cipher suites can be negotiated from I2/R2 packet.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length | Value ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MKI : It is similar to SPI i.e, to identify the Master key and		Type (8 bits): specifies the type of the parameter.
	also security associations.
	Master Key and its length - obtained from Diffie Hellmann key		Length (8 bits): specifies the length of the Value field (in bytes).
	exchange
	session keys is derived using Master key and SP		Value (variable length): specifies the value of the parameter.
	0 1 2 3		Type | Length | Meaning | Value
	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		-----+--------+----------------------------+--------------------
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		1 | 1 | SRTP and SRTCP encr transf | see below
	| Type | Length |		2 | 2 | Encr session key length | 128
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		3 | 1 | SRTP and SRTCP auth transf | see below
	| Encr. transf | Auth transf | Encr length |		4 | 2 | Auth session key length | 160
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		5 | 2 | Tag length | 80
	| Auth Length | tag length |		6 | 4 | SRTP prefix_length | var(default 0)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		7 | 1 | Key derivation PRF | see below
	|FEC| Reserved | SRTP prefix length |		8 | 8 | Key derivation rate | var(default 0)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		9 | 8 | SRTP-packets-max-lifetime | var
	| SRTP prefix length | |		10 | 8 | SRTCP-packets-max-lifetime | var
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		11 | 1 | Forward Error Control | 2-bits
	| SRTP-packets-max-lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key derivation rate |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRTCP-packets-max-lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fig 4: Key management parameters		For the Encryption transforms, a one byte length is enough. The
			currently defined possible values are:
	Type: 40000 (experimental identifier range)		SRTP and SRTCP encr transf | Value
	Length: 256 bit		---------------------------+------
	Value: Type/Meaning | Possible values		NULL | 0
	-------------------------------------------------------		AES-CM | 1
	SRTP and SRTCP encr transf | see below		AES-F8 | 2
	SRTP and SRTCP auth transf. | see below
	tag length | 80
	SRTP prefix_length | variable (default 0)
	Key derivation PRF | see below
	encr session key length | 128
	auth session key length | 160
	key derivation rate | variable (default 0)
	SRTP-packets-max-lifetime | variable
	SRTCP-packets-max-lifetime | variable
	Forward Error Control | 2-bits
	SRTP and SRTCP encr transf. | Value		where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [RFC3711].
	---------------------------------
	NULL | 0
	AES_CM | 1
	AES_f8 | 2
	SRTP and SRTCP auth transf. | Value		For the Authentication transforms, a one byte length is enough. The
	---------------------------------		currently defined possible Values are:
	NULL | 0
	HMAC-SHA1 | 1
	Key derivation PRF | Value		SRTP and SRTCP auth transf | Value
	---------------------------------		----------------------------+------
	NULL | 0		NULL | 0
	AES_CM | 1		HMAC-SHA-1 | 1
	0 1 2 3		For the Key derivation PRF, a one byte length is enough. The
	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		currently defined possible values are:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ MKI (variable) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Fig 5: SRTP MKI parameter		Key derivation PRF | Value
			------------------------+-------
			NULL | 0
			AES_CM | 1
	Type: 40001 (experimental identifier range)		5.4. Master Key Identifier (MKI)
	Length: variable
	Value: Master Key Identifier (MKI)
	4. Key management		The MKI identifies the master key and master salt from which the
			session key(s) were derived that authenticate and/or encrypt the
			particular packet.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ MKI (variable) ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Fig 7: SRTP MKI parameter
			Type: 40001 (experimental identifier range)
			Length: variable
			Value: Master Key Identifier (MKI)
			6. Key management
	This section explains how the key management scheme can be used for		This section explains how the key management scheme can be used for
	the data traffic. After the initial base exchange, both peers have		the data traffic. After the initial base exchange, both peers have
	the same master key, salt and agreed crypto transforms (including		the same master key, salt and agreed crypto transforms (including
	pseudo random function). When the application receives the data		pseudo random function). When the application receives the data
	traffic after the base exchange, an API is invoked and asks the HIP		traffic after the base exchange, an API is invoked and asks the HIP
	daemon for the appropriate key to process the data packet		daemon for the appropriate key to process the data packet.
	The SRTP based key derivation helps to generate the session keys for		The SRTP based key derivation helps to generate the session keys for
	both peers, so that they have the same keys in possession for		both peers, so that they have the same keys in possession for
	encrypting/decrypting the incoming packets. It generates three keys		encrypting/decrypting the incoming packets. It generates three keys
	namely encryption key to provide confidentiality for the data		namely encryption key to provide confidentiality for the data
	packets, authentication key for providing integrity and salt key for		packets, authentication key for providing integrity and salt key for
	the AES counter mode. For that, it uses the master key, salt and		the AES counter mode. For that, it uses the master key, salt and
	crypto transforms together with the packet index.		crypto transforms together with the packet index.
	Figure 6 depicts the example implementation architecture of the		Figure 6 depicts the example implementation architecture of the
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 43 ¶
	User space |		User space |
	-------------+		-------------+
	PF_INET || || PF_RAW		PF_INET || || PF_RAW
	==================||==========||=============		==================||==========||=============
	|| ||		|| ||
	Kernel space		Kernel space
	+--------------+		+--------------+
	| TCP|UDP / IP |		| TCP|UDP / IP |
	+--------------+		+--------------+
	Fig 6: Example Implementation Architecture		Fig 5: Example Implementation Architecture
	Figure 7 depicts the key derivation, for example, when the peer		Figure 6 depicts the key derivation, for example, when the peer
	receives a packet it gets the packet index, MKI, which is used for		receives a packet it gets the packet index, MKI, which is used for
	identifying the relevant master key and transforms. Then, the key		identifying the relevant master key and transforms. Then, the key
	derivation function, which is explained below, will generate the		derivation function, which is explained below, will generate the
	required keys.		required keys.
	packet index ---+		packet index ---+
	|		|
	v		v
	+-----------+ master +--------+ session encr_key		+-----------+ master +--------+ session encr_key
	| ext | key | |---------->		| ext | key | |---------->
	| key mgmt |-------->| key | session auth_key		| key mgmt |-------->| key | session auth_key
	| (optional | | deriv |---------->		| (optional | | deriv |---------->
	| rekey) |-------->| | session salt_key		| rekey) |-------->| | session salt_key
	| | master | |---------->		| | master | |---------->
	+-----------+ salt +--------+		+-----------+ salt +--------+
	Fig 7: SRTP Key Derivation		Fig 6: SRTP Key Derivation
	For single key derivation (key_derivation_rate = 0), we define x for		For single key derivation (key_derivation_rate = 0), we define x for
	later use in calculating keys using PRF and length of PRF bit string		later use in calculating keys using PRF and length of PRF bit string
	output like shown in the following table:		output like shown in the following table:
	X ROC || SEQ Usage PRF output length n		X ROC || SEQ Usage PRF output length n
	---------------------------------------------------------------		---------------------------------------------------------------
	0x00 000000000000 SRTP encryption 128 bit		0x00 000000000000 SRTP encryption 128 bit
	0x01 000000000000 SRTP message auth. 160 bit		0x01 000000000000 SRTP message auth. 160 bit
	0x02 000000000000 SRTP salting key 112 bit		0x02 000000000000 SRTP salting key 112 bit
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	0x01 for SRTP message authentication		0x01 for SRTP message authentication
	0x02 for SRTP salting key		0x02 for SRTP salting key
	0x03 for SRTCP encryption key		0x03 for SRTCP encryption key
	0x04 for SRTCP authentication key		0x04 for SRTCP authentication key
	0x05 for SRTCP salting key		0x05 for SRTCP salting key
	Finally, x is calculated by performing key_id XOR master_salt,		Finally, x is calculated by performing key_id XOR master_salt,
	where key_id and master_salt are aligned so that their least		where key_id and master_salt are aligned so that their least
	significant bits agree (right-alignment).		significant bits agree (right-alignment).
	5. Security Considerations		7. Security Considerations
	Security is considered throughout this document
	The initial keying material is generated using using Diffie-Hellman		The initial keying material is generated using using Diffie-Hellman
	procedure. This document extends the usage of UDPATE packet, defined		procedure. This document extends the usage of UDPATE packet, defined
	in the base specification, for rekeying. The hosts may rekey for the		in the base specification, for rekeying. The hosts may rekey for the
	generation of new keying material using Diffie-Hellman procedure.		generation of new keying material using Diffie-Hellman procedure.
	This mechanism enjoys the security protection provided by base		This mechanism enjoys the security protection provided by base
	exchange using HMAC and signature verifications.		exchange using HMAC and signature verifications.
	In this approach, we have tried to extend the HIP base exchange to		In this approach, we have tried to extend the HIP base exchange to
	support SRTP based key management scheme. We have listed the		support SRTP based key management scheme. We have listed the
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 5 ¶
	MitM: HIP uses authenticated Diffie-Hellmann key exchange, which		MitM: HIP uses authenticated Diffie-Hellmann key exchange, which
	prevents the man-in-the-middle (MitM) attacks.		prevents the man-in-the-middle (MitM) attacks.
	Eavesdropping : Since the data traffic is encrypted, it is		Eavesdropping : Since the data traffic is encrypted, it is
	unreadable for the attackers.		unreadable for the attackers.
	Authentication: Both peers are authenticated using asymmetric key		Authentication: Both peers are authenticated using asymmetric key
	(signature verification) cryptography assuming that public keys		(signature verification) cryptography assuming that public keys
	can be acquired by secure ways.		can be acquired by secure ways.
	6. References		8. Acknowledgements
	6.1 Normative References		The authors would like to gratefully acknowlege Pekka Nikander and
			Jari Arkko for their comments to this document.
			9. References
			9.1. Normative References
	[I-D.ietf-hip-base]		[I-D.ietf-hip-base]
	Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	"Host Identity Protocol", draft-ietf-hip-base-02 (work in		"Host Identity Protocol", draft-ietf-hip-base-03 (work in
	progress), February 2005.		progress), June 2005.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	6.2 Informative References		[RFC3711] Baugher, M., Carrara, E., McGrew, D., Naslund, M., and K.
			Norrman, "The Secure Real-time Transport Protocol
			(SRTP)", March 2004.
			9.2. Informative References
	[I-D.ietf-hip-esp]		[I-D.ietf-hip-esp]
	Moskowitz, R., Nikander, P., and P. Jokela, "Host Identity		Moskowitz, R., Nikander, P., and P. Jokela, "Host Identity
	Protocol", draft-ietf-hip-esp-00 (work in progress),		Protocol", draft-ietf-hip-esp-00 (work in progress),
	June 2005.		June 2005.
	[I-D.ietf-hip-multi6]		[I-D.ietf-hip-multi6]
	Tschofenig, H. and A. Nagarajan, "Comparative Analysis of		Tschofenig, H. and A. Nagarajan, "Comparative Analysis of
	Multi6 Proposals using a Locator/Identifier Split",		Multi6 Proposals using a Locator/Identifier Split",
	October 2004.		October 2004.
	[I-D.ietf-hip-sip]		[I-D.ietf-hip-sip]
	Tschofenig, H., Schulzrinne, H., Henderson, T., Torvinen,		Tschofenig, H., Schulzrinne, H., Henderson, T., Torvinen,
	V., Camarillo, G., and J. ott, "Exchanging Host Identities		V., Camarillo, G., and J. ott, "Exchanging Host Identities
	in SIP", October 2004.		in SIP", October 2004.
	[RFC3261] Schulzrinne, H., Camarillo, G., Rosenberg, J., Peterson,		[RFC3261] Schulzrinne, H., Camarillo, G., Rosenberg, J., Peterson,
	J., Sparks, R., Handley, M., and E. Schooler, "Session		J., Sparks, R., Handley, M., and E. Schooler, "Session
	Initiation Protocol", February 2005.		Initiation Protocol", February 2005.
	[RFC3711] Baugher, M., Carrara, E., McGrew, D., Naslund, M., and K.
	Norrman, "The Secure Real-time Transport Protocol
	(SRTP)", March 2004.
	[RFC3830] Arrko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
	Norrman, "MIKEY: Multimedia Internet KEYing",
	draft-ietf-hip-base-02 (work in progress), August 2004.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
End of changes. 80 change blocks.
	311 lines changed or deleted		297 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/