draft-ietf-perc-private-media-framework-03.txt		draft-ietf-perc-private-media-framework-04.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft D. Benham		Internet-Draft D. Benham
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: September 14, 2017 C. Groves		Expires: January 4, 2018 C. Groves
	Huawei		Huawei
	March 13, 2017		July 3, 2017
	A Solution Framework for Private Media in Privacy Enhanced RTP		A Solution Framework for Private Media in Privacy Enhanced RTP
	Conferencing		Conferencing
	draft-ietf-perc-private-media-framework-03		draft-ietf-perc-private-media-framework-04
	Abstract		Abstract
	This document describes a solution framework for ensuring that media		This document describes a solution framework for ensuring that media
	confidentiality and integrity are maintained end-to-end within the		confidentiality and integrity are maintained end-to-end within the
	context of a switched conferencing environment where media		context of a switched conferencing environment where media
	distribution devices are not trusted with the end-to-end media		distribution devices are not trusted with the end-to-end media
	encryption keys. The solution aims to build upon existing security		encryption keys. The solution aims to build upon existing security
	mechanisms defined for the real-time transport protocol (RTP).		mechanisms defined for the real-time transport protocol (RTP).
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 September 14, 2017.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 4		3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 5
	3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5		3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 5		3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 6
	3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6		3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 6
	3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 6		3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7		3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7		3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7
	4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7		4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 7
	4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 7		4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8
	4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 8		4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9
	4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9		4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 9
	4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 9		4.4. HBH Keys and Hop Operations . . . . . . . . . . . . . . . 10
	4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10		4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10
	4.5.1. Initial Key Exchange and Key Distributor . . . . . . 10		4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11
	4.5.2. Key Exchange during a Conference . . . . . . . . . . 11		4.5.2. Key Exchange during a Conference . . . . . . . . . . 11
	5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Entity Trust . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12		5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 12
	5.2. Certificate Fingerprints in Session Signaling . . . . . . 13		5.2. Certificate Fingerprints in Session Signaling . . . . . . 13
	5.3. Conferences Identification . . . . . . . . . . . . . . . 13		5.3. Conferences Identification . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14		6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14
	6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14		6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 14
	6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14		6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 14
	6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15		6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 15
	6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15		6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 15
	6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15		6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 18
			A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 19
			A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20
			A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 20
			A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21
			Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Switched conferencing is an increasingly popular model for multimedia		Switched conferencing is an increasingly popular model for multimedia
	conferences with multiple participants using a combination of audio,		conferences with multiple participants using a combination of audio,
	video, text, and other media types. With this model, real-time media		video, text, and other media types. With this model, real-time media
	flows from conference participants are not mixed, transcoded,		flows from conference participants are not mixed, transcoded,
	transrated, recomposed, or otherwise manipulated by a Media		transrated, recomposed, or otherwise manipulated by a Media
	Distributor, as might be the case with a traditional media server or		Distributor, as might be the case with a traditional media server or
	multipoint control unit (MCU). Instead, media flows transmitted by		multipoint control unit (MCU). Instead, media flows transmitted by
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 14 ¶
	3.1.1. Media Distributor		3.1.1. Media Distributor
	A Media Distributor forwards RTP flows between endpoints in the		A Media Distributor forwards RTP flows between endpoints in the
	conference while performing per-hop authentication of each RTP		conference while performing per-hop authentication of each RTP
	packet. The Media Distributor may need access to one or more RTP		packet. The Media Distributor may need access to one or more RTP
	headers or header extensions, potentially adding or modifying a		headers or header extensions, potentially adding or modifying a
	certain subset. The Media Distributor will also relay secured		certain subset. The Media Distributor will also relay secured
	messaging between the endpoints and the Key Distributor and will		messaging between the endpoints and the Key Distributor and will
	acquire per-hop key information from the Key Distributor. The actual		acquire per-hop key information from the Key Distributor. The actual
	media content MUST NOT not be decryptable by a Media Distributor, so		media content *MUST NOT* not be decryptable by a Media Distributor,
	it is untrusted to have access to the E2E media encryption keys,		so it is untrusted to have access to the E2E media encryption keys,
	which this framework's key exchange mechanisms will prevent.		which this framework's key exchange mechanisms will prevent.
	An endpoint's ability to join a conference hosted by a Media		An endpoint's ability to join a conference hosted by a Media
	Distributor MUST NOT alone be interpreted as being authorized to have		Distributor MUST NOT alone be interpreted as being authorized to have
	access to the E2E media encryption keys, as the Media Distributor		access to the E2E media encryption keys, as the Media Distributor
	does not have the ability to determine whether an endpoint is		does not have the ability to determine whether an endpoint is
	authorized. Trusted endpoint authorization is described in		authorized. Trusted endpoint authorization is described in
	[I-D.ietf-roach-perc-webrtc].		[I-D.roach-perc-webrtc].
	A Media Distributor MUST perform its role in properly forwarding		A Media Distributor MUST perform its role in properly forwarding
	media packets while taking measures to mitigate the adverse effects		media packets while taking measures to mitigate the adverse effects
	of denial of service attacks (refer to Section 6), etc, to a level		of denial of service attacks (refer to Section 6), etc, to a level
	equal to or better than traditional conferencing (i.e. non-PERC)		equal to or better than traditional conferencing (i.e. non-PERC)
	deployments.		deployments.
	A Media Distributor or associated conferencing infrastructure may		A Media Distributor or associated conferencing infrastructure may
	also initiate or terminate various conference control related		also initiate or terminate various conference control related
	messaging, which is outside the scope of this framework document.		messaging, which is outside the scope of this framework document.
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 16 ¶
	This solution framework focuses on the end-to-end privacy and		This solution framework focuses on the end-to-end privacy and
	integrity of the participant's media by limiting access of the end-		integrity of the participant's media by limiting access of the end-
	to-end key information to trusted entities. However, this framework		to-end key information to trusted entities. However, this framework
	does give a Media Distributor access to RTP headers and all or most		does give a Media Distributor access to RTP headers and all or most
	header extensions, as well as the ability to modify a certain subset		header extensions, as well as the ability to modify a certain subset
	of those headers and to add header extensions. Packets received by a		of those headers and to add header extensions. Packets received by a
	Media Distributor or an endpoint are authenticated hop-by-hop.		Media Distributor or an endpoint are authenticated hop-by-hop.
	To enable all of the above, this framework defines the use of two		To enable all of the above, this framework defines the use of two
	security contexts and two associated encryption keys; an "inner" key		security contexts and two associated encryption keys: an "inner" key
	(E2E Key(i); i={a given endpoint}) for authenticated encryption of		(an E2E key distinct for each transmitted media flow) for
	RTP media between endpoints and an "outer" key (HBH Key(j); j={a		authenticated encryption of RTP media between endpoints and an
	given hop}) for the hop between an endpoint and a Media Distributor		"outer" key (HBH key) known only to media distributor and the
	or between Media Distributor. Reference the following figure.		adjacent endpoint) for the hop between an endpoint and a Media
			Distributor or between Media Distributor. Reference the following
			figure.
	+-------------+ +-------------+		+-------------+ +-------------+
	| |################################| |		| |################################| |
	| Media |------------------------------->| Media |		| Media |------------------------------->| Media |
	| Distributor |<-------------------------------| Distributor |		| Distributor |<-------------------------------| Distributor |
	| X |################################| Y |		| X |################################| Y |
	| | HBH Key (XY) | |		| | HBH Key (XY) | |
	+-------------+ +-------------+		+-------------+ +-------------+
	# ^ | # # ^ | #		# ^ | # # ^ | #
	# | | # HBH HBH # | | #		# | | # HBH HBH # | | #
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 44 ¶
	# | | # # | | #		# | | # # | | #
	# |<+--#---- E2E Key (A) E2E Key (B) ---#->| | #		# |<+--#---- E2E Key (A) E2E Key (B) ---#->| | #
	# | | # # | | #		# | | # # | | #
	# | v # # | v #		# | v # # | v #
	+-------------+ +-------------+		+-------------+ +-------------+
	| Endpoint A | | Endpoint B |		| Endpoint A | | Endpoint B |
	+-------------+ +-------------+		+-------------+ +-------------+
	E2E and HBH Keys Used for Authenticated Encryption		E2E and HBH Keys Used for Authenticated Encryption
	The PERC Double draft specification [I-D.ietf-perc-double] uses		The PERC Double specification [I-D.ietf-perc-double] uses standard
	standard SRTP keying material and recommended cryptographic		SRTP keying material and recommended cryptographic transform(s) to
	transform(s) to first form the inner, end-to-end SRTP cryptographic		first form the inner, end-to-end SRTP cryptographic context. That
	context. That end-to-end SRTP cryptographic context MAY be used to		end-to-end SRTP cryptographic context MAY be used to encrypt some RTP
	encrypt some RTP header extensions along with RTP media content. The		header extensions along with RTP media content. The output of this
	output of this is treated like an RTP packet and encrypted again		is treated like an RTP packet and encrypted again using the outer
	using the outer hop-by-hop cryptographic context. The endpoint		hop-by-hop cryptographic context. The endpoint executes the entire
	executes the entire Double operation while the Media Distributor just		Double operation while the Media Distributor just performs the outer,
	performs the outer, hop-by-hop operation.		hop-by-hop operation. (See Appendix A for a description of the keys
			used in PERC and Appendix B for an overview of how the packet appears
			on the wire.)
	RTCP can only be encrypted hop-by-hop, not end-to-end. This		RTCP can only be encrypted hop-by-hop, not end-to-end. This
	framework introduces no additional step for RTCP authenticated		framework introduces no additional step for RTCP authenticated
	encryption, so the procedures needed are specified in [RFC3711] and		encryption, so the procedures needed are specified in [RFC3711] and
	use the same outer, hop-by-hop cryptographic context chosen in the		use the same outer, hop-by-hop cryptographic context chosen in the
	Double operation described above.		Double operation described above.
	4.2. E2E Key Confidentiality		4.2. E2E Key Confidentiality
	To ensure the confidentiality of E2E keys shared between endpoints,		To ensure the confidentiality of E2E keys shared between endpoints,
	endpoints will make use of a common Key Encryption Key (KEK) that is		endpoints will make use of a common Key Encryption Key (KEK) that is
	known only by the trusted entities in a conference. That KEK,		known only by the trusted entities in a conference. That KEK,
	defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKTKey,		defined in the PERC EKT [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key,
	will be used to subsequently encrypt SRTP master keys used for E2E		will be used to subsequently encrypt the SRTP master key used for E2E
	authenticated encryption (E2E Key(i); i={a given endpoint}) of media		authenticated encryption of media sent by a given endpoint. Each
	sent by a given endpoint.		endpoint in the conference will create a random SRTP master key for
			E2E authenticated encryption, thus participants in the conference
	+----------------------+------------+-------+-------+------------+		MUST keep track of the E2E keys received via the Full EKT Field for
	| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |		each distinct SSRC in the conference so that it can properly decrypt
	+----------------------+------------+-------+-------+------------+		received media. Note, too, that an endpoint may change its E2E key
	| KEK | Yes | No | No | Yes |		at any time and advertise that new key to the conference as specified
	+----------------------+------------+-------+-------+------------+		in [I-D.ietf-perc-srtp-ekt-diet].
	| E2E Key (i) | Yes | No | No | Yes |
	+----------------------+------------+-------+-------+------------+
	| HBH Key (A<=>MD X) | Yes | Yes | No | No |
	+----------------------+------------+-------+-------+------------+
	| HBH Key (B<=>MD Y) | No | No | Yes | Yes |
	+----------------------+------------+---------------+------------+
	| HBH Key (MD X<=>MD Y)| No | Yes | Yes | No |
	+----------------------+------------+---------------+------------+
	Figure 2: Keys per Entity
	4.3. E2E Keys and Endpoint Operations		4.3. E2E Keys and Endpoint Operations
	Any given RTP media flow can be identified by its SSRC, and endpoints		Any given RTP media flow can be identified by its SSRC, and endpoints
	might send more than one at a time and change the mix of media flows		might send more than one at a time and change the mix of media flows
	transmitted during the life of a conference.		transmitted during the life of a conference.
	Thus, endpoints MUST maintain a list of SSRCs from received RTP flows		Thus, endpoints MUST maintain a list of SSRCs from received RTP flows
	and each SSRC's associated E2E Key(i) information. Following a		and each SSRC's associated E2E key information. Following a change
	change of the KEK (i.e., EKTKey), prior E2E Key(i) information SHOULD		in an E2E key, prior E2E keys SHOULD be retained by receivers for a
	be retained for a period long enough to ensure that late-arriving or		period long enough to ensure that late-arriving or out-of-order
	out-of-order packets from other endpoints can be successfully		packets from the endpoint can be successfully decrypted. Receiving
	decrypted. The endpoint MUST discard the E2E Key(i) and KEK		endpoints MUST discard old E2E keys no later than when it leaves the
	information no later than when it leaves the conference.		conference.
	If there is a need to encrypt one or more RTP header extensions end-		If there is a need to encrypt one or more RTP header extensions end-
	to-end, an encryption key is derived from the end-to-end SRTP master		to-end, an encryption key is derived from the end-to-end SRTP master
	key to encrypt header extensions as per [RFC6904]. The Media		key to encrypt header extensions as per [RFC6904]. The Media
	Distributor will not be able use the information contained in those		Distributor will not be able use the information contained in those
	header extensions encrypted with E2E keys.		header extensions encrypted with an E2E key.
	4.4. HBH Keys and Hop Operations		4.4. HBH Keys and Hop Operations
	To ensure the integrity of transmitted media packets, this framework		To ensure the integrity of transmitted media packets, this framework
	requires that every packet be authenticated hop-by-hop (HBH) between		requires that every packet be authenticated hop-by-hop (HBH) between
	an endpoint and a Media Distributor, as well between Media		an endpoint and a Media Distributor, as well between Media
	Distributors. The authentication key used for hop-by-hop		Distributors. The authentication key used for hop-by-hop
	authentication is derived from an SRTP master key shared only on the		authentication is derived from an SRTP master key shared only on the
	respective hop (HBH Key(j); j={a given hop}). Each HBH Key(j) is		respective hop. Each HBH key is distinct per hop and no two hops
	distinct per hop and no two hops ever intentionally use the same SRTP		ever intentionally use the same SRTP master key.
	master key.
	Using hop-by-hop authentication gives the Media Distributor the		Using hop-by-hop authentication gives the Media Distributor the
	ability to change certain RTP header values. Which values the Media		ability to change certain RTP header values. Which values the Media
	Distributor can change in the RTP header are defined in		Distributor can change in the RTP header are defined in
	[I-D.ietf-perc-double]. RTCP can only be encrypted, giving the Media		[I-D.ietf-perc-double]. RTCP can only be encrypted, giving the Media
	Distributor the flexibility to forward RTCP content unchanged,		Distributor the flexibility to forward RTCP content unchanged,
	transmit compound RTCP packets or to initiate RTCP packets for		transmit compound RTCP packets or to initiate RTCP packets for
	reporting statistics or conveying other information. Performing hop-		reporting statistics or conveying other information. Performing hop-
	by-hop authentication for all RTP and RTCP packets also helps provide		by-hop authentication for all RTP and RTCP packets also helps provide
	replay protection (see Section 6).		replay protection (see Section 6).
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 48 ¶
	Distributor, this framework utilizes a DTLS-SRTP [RFC5764]		Distributor, this framework utilizes a DTLS-SRTP [RFC5764]
	association between an endpoint and the Key Distributor. To		association between an endpoint and the Key Distributor. To
	establish this association, an endpoint will send DTLS-SRTP messages		establish this association, an endpoint will send DTLS-SRTP messages
	to the Media Distributor which will then forward them to the Key		to the Media Distributor which will then forward them to the Key
	Distributor as defined in [I-D.ietf-perc-dtls-tunnel]. The Key		Distributor as defined in [I-D.ietf-perc-dtls-tunnel]. The Key
	Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key		Encryption Key (KEK) (i.e., EKTKey) is also conveyed by the Key
	Distributor over the DTLS association to endpoints via procedures		Distributor over the DTLS association to endpoints via procedures
	defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet].		defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet].
	Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media		Media Distributors use DTLS-SRTP [RFC5764] directly with a peer Media
	Distributor to establish HBH keys for transmitting RTP and RTCP		Distributor to establish the HBH key for transmitting RTP and RTCP
	packets to that peer Media Distributor. The Key Distributor does not		packets to that peer Media Distributor. The Key Distributor does not
	facilitate establishing HBH keys for use between Media Distributors.		facilitate establishing a HBH key for use between Media Distributors.
	4.5.1. Initial Key Exchange and Key Distributor		4.5.1. Initial Key Exchange and Key Distributor
	The procedures defined in DTLS Tunnel for PERC		The procedures defined in DTLS Tunnel for PERC
	[I-D.ietf-perc-dtls-tunnel] establish one or more TLS tunnels between		[I-D.ietf-perc-dtls-tunnel] establish one or more TLS tunnels between
	the Media Distributor and Key Distributor, making it is possible for		the Media Distributor and Key Distributor, making it is possible for
	the Media Distributor to facilitate the establishment of a secure		the Media Distributor to facilitate the establishment of a secure
	DTLS association between each endpoint and the Key Distributor as		DTLS association between each endpoint and the Key Distributor as
	shown the following figure. The DTLS association between endpoints		shown the following figure. The DTLS association between endpoints
	and the Key Distributor will enable each endpoint to receive E2E key		and the Key Distributor will enable each endpoint to receive E2E key
	information, Key Encryption Key (KEK) information (i.e., EKTKey), and		information, Key Encryption Key (KEK) information (i.e., EKT Key),
	HBH key information. At the same time, the Key Distributor can		and HBH key information. At the same time, the Key Distributor can
	securely provide the HBH key information to the Media Distributor.		securely provide the HBH key information to the Media Distributor.
	The key information summarized here may include the SRTP master key,		The key information summarized here may include the SRTP master key,
	SRTP master salt, and the negotiated cryptographic transform.		SRTP master salt, and the negotiated cryptographic transform.
	+-----------+		+-----------+
	KEK info | Key | HBH Key info to		KEK info | Key | HBH Key info to
	to Endpoints |Distributor| Endpoints & Media Distributor		to Endpoints |Distributor| Endpoints & Media Distributor
	+-----------+		+-----------+
	# ^ ^ #		# ^ ^ #
	# | | #-TLS Tunnel		# | | #-TLS Tunnel
	# | | #		# | | #
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	| Endpoint | DTLS | Media | DTLS | Endpoint |		| Endpoint | DTLS | Media | DTLS | Endpoint |
	| KEK |<------------|Distributor|------------>| KEK |		| KEK |<------------|Distributor|------------>| KEK |
	| HBH Key(j)| to Key Dist | HBH Keys | to Key Dist | HBH Key(j)|		| HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	Figure 3: Exchanging Key Information Between Entities		Figure 2: Exchanging Key Information Between Entities
	Endpoints will establish a DTLS-SRTP association over the RTP		Endpoints will establish a DTLS-SRTP association over the RTP
	session's media ports for the purposes of key information exchange		session's media ports for the purposes of key information exchange
	with the Key Distributor. The Media Distributor will not terminate		with the Key Distributor. The Media Distributor will not terminate
	the DTLS signaling, but will instead forward DTLS packets received		the DTLS signaling, but will instead forward DTLS packets received
	from an endpoint on to the Key Distributor (and vice versa) via a		from an endpoint on to the Key Distributor (and vice versa) via a
	tunnel established between Media Distributor and the Key Distributor.		tunnel established between Media Distributor and the Key Distributor.
	This tunnel is used to encapsulate the DTLS-SRTP signaling between		This tunnel is used to encapsulate the DTLS-SRTP signaling between
	the Key Distributor and endpoints will also be used to convey HBH key		the Key Distributor and endpoints will also be used to convey HBH key
	information from the Key Distributor to the Media Distributor, so no		information from the Key Distributor to the Media Distributor, so no
	additional protocol or interface is required.		additional protocol or interface is required.
	4.5.2. Key Exchange during a Conference		4.5.2. Key Exchange during a Conference
	Following the initial key information exchange with the Key		Following the initial key information exchange with the Key
	Distributor, endpoints will be able to encrypt media end-to-end with		Distributor, an endpoints will be able to encrypt media end-to-end
	their E2E Key(i), sending that E2E Key(i) to other endpoints		with an E2E key, sending that E2E key to other endpoints encrypted
	encrypted with KEK, and will be able to encrypt and authenticate RTP		with the KEK, and will be able to encrypt and authenticate RTP
	packets using local HBH Key(j). The procedures defined do not allow		packets using a HBH key. The procedures defined do not allow the
	the Media Distributor to gain access to the KEK information,		Media Distributor to gain access to the KEK information, preventing
	preventing it from gaining access to any endpoint's E2E key and		it from gaining access to any endpoint's E2E key and subsequently
	subsequently decrypting media.		decrypting media.
	The KEK (i.e., EKTKey) may need to change from time-to-time during		The KEK (i.e., EKT Key) may need to change from time-to-time during
	the life of a conference, such as when a new participant joins or		the life of a conference, such as when a new participant joins or
	leaves a conference. Dictating if, when or how often a conference is		leaves a conference. Dictating if, when or how often a conference is
	to be re-keyed is outside the scope of this document, but this		to be re-keyed is outside the scope of this document, but this
	framework does accommodate re-keying during the life of a conference.		framework does accommodate re-keying during the life of a conference.
	When a Key Distributor decides to rekey a conference, it transmits a		When a Key Distributor decides to re-key a conference, it transmits a
	specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to		specific message defined in PERC EKT [I-D.ietf-perc-srtp-ekt-diet] to
	each of the conference participants. The endpoint MUST create a new		each of the conference participants. The endpoint MUST create a new
	SRTP master key and prepare to send that key inside a Full EKT Field		SRTP master key and prepare to send that key inside a Full EKT Field
	using the new EKTKey. Since it may take some time for all of the		using the new EKTKey. Since it may take some time for all of the
	endpoints in conference to finish re-keying, senders MUST delay a		endpoints in conference to finish re-keying, senders MUST delay a
	short period of time before sending media encrypted with the new		short period of time before sending media encrypted with the new
	master key, but it MUST be prepared to make use of the information		master key, but it MUST be prepared to make use of the information
	from a new inbound EKTKey immediately. See Section 2.2.2 of		from a new inbound EKT Key immediately. See Section 2.2.2 of
	[I-D.ietf-perc-srtp-ekt-diet].		[I-D.ietf-perc-srtp-ekt-diet].
	5. Entity Trust		5. Entity Trust
	It is important to this solution framework that the entities can		It is important to this solution framework that the entities can
	trust and validate the authenticity of other entities, especially the		trust and validate the authenticity of other entities, especially the
	Key Distributor and endpoints. The details of this are outside the		Key Distributor and endpoints. The details of this are outside the
	scope of specification but a few possibilities are discussed in the		scope of specification but a few possibilities are discussed in the
	following sections. The key requirements is that endpoints can		following sections. The key requirements is that endpoints can
	verify they are connected to the correct Key Distributor for the		verify they are connected to the correct Key Distributor for the
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	invaluable input on this document. Also, we would like to		invaluable input on this document. Also, we would like to
	acknowledge Nermeen Ismail for serving on the initial versions of		acknowledge Nermeen Ismail for serving on the initial versions of
	this document as a co-author.		this document as a co-author.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-perc-double]		[I-D.ietf-perc-double]
	Jennings, C., Jones, P., and A. Roach, "SRTP Double		Jennings, C., Jones, P., and A. Roach, "SRTP Double
	Encryption Procedures", draft-ietf-perc-double-02 (work in		Encryption Procedures", draft-ietf-perc-double-04 (work in
	progress), October 2016.		progress), April 2017.
	[I-D.ietf-perc-dtls-tunnel]		[I-D.ietf-perc-dtls-tunnel]
	Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel		Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
	between a Media Distributor and Key Distributor to		between a Media Distributor and Key Distributor to
	Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00		Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-01
	(work in progress), March 2017.		(work in progress), April 2017.
	[I-D.ietf-perc-srtp-ekt-diet]		[I-D.ietf-perc-srtp-ekt-diet]
	Jennings, C., Mattsson, J., McGrew, D., and D. Wing,		Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
	"Encrypted Key Transport for Secure RTP", draft-ietf-perc-		"Encrypted Key Transport for DTLS and Secure RTP", draft-
	srtp-ekt-diet-02 (work in progress), October 2016.		ietf-perc-srtp-ekt-diet-04 (work in progress), April 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<http://www.rfc-editor.org/info/rfc3711>.		<http://www.rfc-editor.org/info/rfc3711>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764, DOI		Real-time Transport Protocol (SRTP)", RFC 5764,
	10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<http://www.rfc-editor.org/info/rfc5764>.		<http://www.rfc-editor.org/info/rfc5764>.
	[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure		[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
	Real-time Transport Protocol (SRTP)", RFC 6904, DOI		Real-time Transport Protocol (SRTP)", RFC 6904,
	10.17487/RFC6904, April 2013,		DOI 10.17487/RFC6904, April 2013,
	<http://www.rfc-editor.org/info/rfc6904>.		<http://www.rfc-editor.org/info/rfc6904>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-avtcore-rtp-topologies-update]		[I-D.ietf-avtcore-rtp-topologies-update]
	Westerlund, M. and S. Wenger, "RTP Topologies", draft-		Westerlund, M. and S. Wenger, "RTP Topologies", draft-
	ietf-avtcore-rtp-topologies-update-10 (work in progress),		ietf-avtcore-rtp-topologies-update-10 (work in progress),
	July 2015.		July 2015.
	[I-D.ietf-roach-perc-webrtc]
	Roach, A., "Using Privacy Enhanced Real-time Conferencing
	(PERC) in a WebRTC Context", March 2017.
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-12 (work in progress), June 2016.		rtcweb-security-arch-12 (work in progress), June 2016.
			[I-D.roach-perc-webrtc]
			Roach, A., "Using Privacy Enhanced Real-time Conferencing
			(PERC) in a WebRTC Context", draft-roach-perc-webrtc-00
			(work in progress), March 2017.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
	[RFC4353] Rosenberg, J., "A Framework for Conferencing with the		[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
	Session Initiation Protocol (SIP)", RFC 4353, DOI		Session Initiation Protocol (SIP)", RFC 4353,
	10.17487/RFC4353, February 2006,		DOI 10.17487/RFC4353, February 2006,
	<http://www.rfc-editor.org/info/rfc4353>.		<http://www.rfc-editor.org/info/rfc4353>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/		Initiation Protocol (SIP)", RFC 4474,
	RFC4474, August 2006,		DOI 10.17487/RFC4474, August 2006,
	<http://www.rfc-editor.org/info/rfc4474>.		<http://www.rfc-editor.org/info/rfc4474>.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, DOI 10.17487/RFC4566,		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	July 2006, <http://www.rfc-editor.org/info/rfc4566>.		July 2006, <http://www.rfc-editor.org/info/rfc4566>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <http://www.rfc-editor.org/info/rfc5763>.		2010, <http://www.rfc-editor.org/info/rfc5763>.
	[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time		[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
	Transport Protocol (RTP) Header Extension for Client-to-		Transport Protocol (RTP) Header Extension for Client-to-
	Mixer Audio Level Indication", RFC 6464, DOI 10.17487/		Mixer Audio Level Indication", RFC 6464,
	RFC6464, December 2011,		DOI 10.17487/RFC6464, December 2011,
	<http://www.rfc-editor.org/info/rfc6464>.		<http://www.rfc-editor.org/info/rfc6464>.
			Appendix A. PERC Key Inventory
			PERC specifies the use of a number of different keys and,
			understandably, it looks complicated or confusing on the surface.
			This section summarizes the various keys used in the system, how they
			are generated, and what purpose they serve.
			The keys are described in the order in which they would typically be
			acquired.
			The various keys used in PERC are shown in Figure 3 below.
			+-----------+----------------------------------------------------+
			| Key | Description |
			+-----------+----------------------------------------------------+
			| KEK | Key shared by all endpoints and used to encrypt |
			| (EKT Key) | each endpoint's SRTP master key so receiving |
			| | endpoints can decrypt media. |
			+-----------+----------------------------------------------------+
			| HBH Key | Key used to encrypt media hop-by-hop. |
			+-----------+----------------------------------------------------+
			| E2E Key | Key used to encrypt media end-to-end. |
			+-----------+----------------------------------------------------+
			Figure 3: Key Inventory
			As you can see, the number key types is very small. However, what
			can be challenging is keeping track of all of the distinct E2E keys
			as the conference grows in size. With 1,000 participants in a
			conference, there will be 1,000 distinct SRTP master keys, all of
			which share the same master salt. Each of those keys are passed
			through the KDF defined in [RFC3711] to produce the actual encryption
			and authentication keys. Complicating key management is the fact
			that the KEK can change and, when it does, the endpoints generate new
			SRTP master keys. And, of course, there is a new SRTP master salt to
			go with those keys. Endpoints have to retain old keys for a period
			of time to ensure they can properly decrypt late-arriving or out-of-
			order packets.
			The time required to retain old keys (either EKT Keys or SRTP master
			keys) is not specified, but they should be retained at least for the
			period of time required to re-key the conference or handle late-
			arriving or out-of-order packets. A period of 60s should be
			considered a generous retention period, but endpoints may keep old
			keys on hand until the end of the conference.
			Or more detailed explanation of each of the keys follows.
			A.1. DTLS-SRTP Exchange Yields HBH Keys
			The first set of keys acquired are for hop-by-hop encryption and
			decryption. Assuming the use of Double [I-D.ietf-perc-double], the
			endpoint would perform DTLS-SRTP exchange with the key distributor
			and receive a key that is, in fact, "double" the size that is needed.
			Per the Double specification, the E2E part is the first half of the
			key, so the endpoint will just discard that information in PERC. It
			is not used. The second half of the key material is for HBH
			operations, so that half of the key (corresponding to the least
			significant bits) is assigned internally as the HBH key.
			The media distributor doesn't perform DTLS-SRTP, but it is at this
			point that the key distributor will inform the media distributor of
			the HBH key value via the tunnel protocol
			([I-D.ietf-perc-dtls-tunnel]). The key distributor will send the
			least significant bits corresponding to the half of the keying
			material determined through DTLS-SRTP with the endpoint to the media
			distributor via the tunnel protocol. There is a salt generated along
			with the HBH key. The salt is also longer than needed for HBH
			operations, thus only the least significant bits of the required
			length (i.e., half of the generated salt material) are sent to the
			media distributor via the tunnel protocol.
			No two endpoints will have the same HBH key, thus the media
			distributor must keep track each distinct HBH key (and the
			corresponding salt) and use it only for the specified hop.
			This key is also used for HBH encryption of RTCP. RTCP is not end-
			to-end encrypted in PERC.
			A.2. The Key Distributor Transmits the KEK (EKT Key)
			Via the aforementioned DTLS-SRTP association, the key distributor
			will send the endpoint the KEK (i.e., EKT Key per
			[I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the key
			distributor and endpoints. This key is the most important to protect
			since having knowledge of this key (and the SRTP master salt
			transmitted as a part of the same message) will allow an entity to
			decrypt any media packet in the conference.
			Note that the key distributor can send any number of EKT Keys to
			endpoints. This can be used to re-key the entire conference. Each
			key is identified by a "Security Parameter Index" (SPI) value.
			Endpoints should expect that a conference might be re-keyed when a
			new participant joins a conference or when a participant leaves a
			conference in order to protect the confidentiality of the
			conversation before and after such events.
			The SRTP master salt to be used by the endpoint is transmitted along
			with the EKT Key. All endpoints in the conference utilize the same
			SRTP master salt that corresponds with a given EKT Key.
			The EKT Field in media packets is encrypted using a cipher specified
			via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This
			cipher is different than the cipher used to protect media and is only
			used to encrypt the endpoint's SRTP master key (and other EKT Field
			data as per [I-D.ietf-perc-srtp-ekt-diet]).
			The media distributor is not given the KEK (i.e., EKT Key).
			A.3. Endpoints fabricate an SRTP Master Key
			As stated earlier, the E2E key determined via DTLS-SRTP is discarded.
			While it could have been used, the fact that endpoints may need to
			change the SRTP master key periodically or are forced to change the
			SRTP master key as a result of the EKT key changing means using it
			has only limited utility. To reduce complexity, PERC prescribes that
			endpoints manufacturer random SRTP master keys locally to be used for
			E2E encryption.
			This locally-generated SRTP master key is used along with the master
			salt transmitted to the endpoint from the key distributor via the
			EKTKey message to encrypt media end-to-end.
			Since the media distributor is not involved in E2E functions, it will
			not create this key nor have access to any endpoint's E2E key. Note,
			too, that even the key distributor is unaware of the locally-
			generated E2E keys used by each endpoint.
			The endpoint will transmit its E2E key to other endpoints in the
			conference by periodically including it in SRTP packets in a Full EKT
			Field. When placed in the Full EKT Field, it is encrypted using the
			EKT Key provided by the key distributor. The master salt is not
			transmitted, though, since all endpoints will have received the same
			master salt via the EKTKey message. The recommended frequency with
			which an endpoint transmits its SRTP master key is specified in
			[I-D.ietf-perc-srtp-ekt-diet].
			A.4. Who has What Key
			All endpoints have knowledge of the KEK.
			Every HBH key is distinct for a given endpoint, thus Endpoint A and
			endpoint B do not have knowledge of the other's HBH key.
			Each endpoint generates its own E2E Key (SRTP master key), thus the
			key distinct per endpoint. This key is transmitted (encrypted) via
			the EKT Field to other endpoints. Endpoints that receive media from
			a given transmitting endpoint will therefore have knowledge of the
			transmitter's E2E key.
			To summarize the various keys and which entity is in possession of a
			given key, refer to Figure 4.
			+----------------------+------------+-------+-------+------------+
			| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |
			+----------------------+------------+-------+-------+------------+
			| KEK | Yes | No | No | Yes |
			+----------------------+------------+-------+-------+------------+
			| E2E Key (A and B) | Yes | No | No | Yes |
			+----------------------+------------+-------+-------+------------+
			| HBH Key (A<=>MD X) | Yes | Yes | No | No |
			+----------------------+------------+-------+-------+------------+
			| HBH Key (B<=>MD Y) | No | No | Yes | Yes |
			+----------------------+------------+---------------+------------+
			| HBH Key (MD X<=>MD Y)| No | Yes | Yes | No |
			+----------------------+------------+---------------+------------+
			Figure 4: Keys per Entity
			Appendix B. PERC Packet Format
			Figure 5 presents a complete picture of what a PERC packet looks like
			when transmitted over the wire.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			A |V=2|P|X| CC |M| PT | sequence number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			A | timestamp |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			A | synchronization source (SSRC) identifier |
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			A | contributing source (CSRC) identifiers |
			A | .... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			A | RTP extension (OPTIONAL) |
			A | (including the OHB) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			C : :
			C : Ciphertext Payload :
			C : :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			R : :
			R : EKT Field :
			R : :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			C = Ciphertext (encrypted and authenticated)
			A = Associated Data (authenticated only)
			R = neither encrypted nor authenticated, added
			after Authenticated Encryption completed
			Figure 5: PERC Packet Format
	Authors' Addresses		Authors' Addresses
	Paul E. Jones		Paul E. Jones
	Cisco		Cisco
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, North Carolina 27709		Research Triangle Park, North Carolina 27709
	USA		USA
	Phone: +1 919 476 2048		Phone: +1 919 476 2048
	Email: paulej@packetizer.com		Email: paulej@packetizer.com
End of changes. 40 change blocks.
	99 lines changed or deleted		304 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/