< draft-zimmermann-avt-zrtp-22.txt		draft-zimmermann-avt-zrtp-22-with-expected-AUTH48-changes.txt >
	Network Working Group P. Zimmermann		Network Working Group P. Zimmermann
	Internet-Draft Zfone Project		Internet-Draft Zfone Project
	Intended status: Informational A. Johnston, Ed.		Intended status: Informational A. Johnston, Ed.
	Expires: December 19, 2010 Avaya		Expires: January 9, 2011 Avaya
	J. Callas		J. Callas
	Apple, Inc.		Apple, Inc.
	June 17, 2010		July 8, 2010
	ZRTP: Media Path Key Agreement for Unicast Secure RTP		ZRTP: Media Path Key Agreement for Unicast Secure RTP
	draft-zimmermann-avt-zrtp-22		draft-zimmermann-avt-zrtp-22-with-expected-AUTH48-changes
	Abstract		Abstract
	This document defines ZRTP, a protocol for media path Diffie-Hellman		This document defines ZRTP, a protocol for media path Diffie-Hellman
	exchange to agree on a session key and parameters for establishing		exchange to agree on a session key and parameters for establishing
	unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP		unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP
	applications. The ZRTP protocol is media path keying because it is		applications. The ZRTP protocol is media path keying because it is
	multiplexed on the same port as RTP and does not require support in		multiplexed on the same port as RTP and does not require support in
	the signaling protocol. ZRTP does not assume a Public Key		the signaling protocol. ZRTP does not assume a Public Key
	Infrastructure (PKI) or require the complexity of certificates in end		Infrastructure (PKI) or require the complexity of certificates in end
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	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 December 19, 2010.		This Internet-Draft will expire on January 9, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 4, line 40		skipping to change at page 4, line 40
	5.16. PingACK message . . . . . . . . . . . . . . . . . . . . . 72		5.16. PingACK message . . . . . . . . . . . . . . . . . . . . . 72
	6. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 73		6. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 73
	7. Short Authentication String . . . . . . . . . . . . . . . . . 76		7. Short Authentication String . . . . . . . . . . . . . . . . . 76
	7.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 77		7.1. SAS Verified Flag . . . . . . . . . . . . . . . . . . . . 77
	7.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 78		7.2. Signing the SAS . . . . . . . . . . . . . . . . . . . . . 78
	7.2.1. OpenPGP Signatures . . . . . . . . . . . . . . . . . 79		7.2.1. OpenPGP Signatures . . . . . . . . . . . . . . . . . 79
	7.2.2. NSA Suite B Signatures with X.509v3 Certs . . . . . . 81		7.2.2. NSA Suite B Signatures with X.509v3 Certs . . . . . . 81
	7.2.3. Signing the SAS without a PKI . . . . . . . . . . . . 82		7.2.3. Signing the SAS without a PKI . . . . . . . . . . . . 82
	7.3. Relaying the SAS through a PBX . . . . . . . . . . . . . 83		7.3. Relaying the SAS through a PBX . . . . . . . . . . . . . 83
	7.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . 85		7.3.1. PBX Enrollment and the PBX Enrollment Flag . . . . . 85
	8. Signaling Interactions . . . . . . . . . . . . . . . . . . . 86		8. Signaling Interactions . . . . . . . . . . . . . . . . . . . 87
	8.1. Binding the media stream to the signaling layer via		8.1. Binding the media stream to the signaling layer via
	the Hello Hash . . . . . . . . . . . . . . . . . . . . . 88		the Hello Hash . . . . . . . . . . . . . . . . . . . . . 88
	8.1.1. Integrity-protected signaling enables		8.1.1. Integrity-protected signaling enables
	integrity-protected DH exchange . . . . . . . . . . . 89		integrity-protected DH exchange . . . . . . . . . . . 89
	8.2. Deriving the SRTP secret (srtps) from the signaling		8.2. Deriving the SRTP secret (srtps) from the signaling
	layer . . . . . . . . . . . . . . . . . . . . . . . . . . 91		layer . . . . . . . . . . . . . . . . . . . . . . . . . . 91
	8.3. Codec Selection for Secure Media . . . . . . . . . . . . 92		8.3. Codec Selection for Secure Media . . . . . . . . . . . . 92
	9. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 92		9. False ZRTP Packet Rejection . . . . . . . . . . . . . . . . . 92
	10. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 94		10. Intermediary ZRTP Devices . . . . . . . . . . . . . . . . . . 94
	11. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . 95		11. The ZRTP Disclosure flag . . . . . . . . . . . . . . . . . . 95
	skipping to change at page 5, line 13		skipping to change at page 5, line 13
	Flag . . . . . . . . . . . . . . . . . . . . . . . . . . 97		Flag . . . . . . . . . . . . . . . . . . . . . . . . . . 97
	12. Mapping between ZID and AOR (SIP URI) . . . . . . . . . . . . 98		12. Mapping between ZID and AOR (SIP URI) . . . . . . . . . . . . 98
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99
	14. Media Security Requirements . . . . . . . . . . . . . . . . . 99		14. Media Security Requirements . . . . . . . . . . . . . . . . . 99
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 101		15. Security Considerations . . . . . . . . . . . . . . . . . . . 101
	15.1. Self-healing Key Continuity Feature . . . . . . . . . . . 104		15.1. Self-healing Key Continuity Feature . . . . . . . . . . . 104
	16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 106		16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 106
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 106		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
	17.1. Normative References . . . . . . . . . . . . . . . . . . 106		17.1. Normative References . . . . . . . . . . . . . . . . . . 106
	17.2. Informative References . . . . . . . . . . . . . . . . . 109		17.2. Informative References . . . . . . . . . . . . . . . . . 108
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112
	1. Introduction		1. Introduction
	ZRTP is a key agreement protocol which performs Diffie-Hellman key		ZRTP is a key agreement protocol which performs Diffie-Hellman key
	exchange during call setup in the media path, and is transported over		exchange during call setup in the media path, and is transported over
	the same port as the Real-time Transport Protocol (RTP) [RFC3550]		the same port as the Real-time Transport Protocol (RTP) [RFC3550]
	media stream which has been established using a signaling protocol		media stream which has been established using a signaling protocol
	such as Session Initiation Protocol (SIP) [RFC3261]. This generates		such as Session Initiation Protocol (SIP) [RFC3261]. This generates
	a shared secret which is then used to generate keys and salt for a		a shared secret which is then used to generate keys and salt for a
	skipping to change at page 43, line 5		skipping to change at page 43, line 5
	(Section 7.3.1) mechanism.		(Section 7.3.1) mechanism.
	5. ZRTP Messages		5. ZRTP Messages
	All ZRTP messages use the message format defined in Figure 2. All		All ZRTP messages use the message format defined in Figure 2. All
	word lengths referenced in this specification are 32 bits or 4		word lengths referenced in this specification are 32 bits or 4
	octets. All integer fields are carried in network byte order, that		octets. All integer fields are carried in network byte order, that
	is, most significant byte (octet) first, commonly known as big-		is, most significant byte (octet) first, commonly known as big-
	endian.		endian.
			0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Not Used (set to zero) | Sequence Number |		|0 0 0 1|Not Used (set to zero) | Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Magic Cookie 'ZRTP' (0x5a525450) |		| Magic Cookie 'ZRTP' (0x5a525450) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Identifier |		| Source Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| ZRTP Message (length depends on Message Type) |		| ZRTP Message (length depends on Message Type) |
	skipping to change at page 49, line 47		skipping to change at page 49, line 47
	parameters defined in [RFC3526], as follows. DH3k uses the 3072-bit		parameters defined in [RFC3526], as follows. DH3k uses the 3072-bit
	MODP group. DH2k uses the 2048-bit MODP group. The DH generator g		MODP group. DH2k uses the 2048-bit MODP group. The DH generator g
	is 2. The random Diffie-Hellman secret exponent SHOULD be twice as		is 2. The random Diffie-Hellman secret exponent SHOULD be twice as
	long as the AES key length. If AES-128 is used, the DH secret value		long as the AES key length. If AES-128 is used, the DH secret value
	SHOULD be 256 bits long. If AES-256 is used, the secret value SHOULD		SHOULD be 256 bits long. If AES-256 is used, the secret value SHOULD
	be 512 bits long.		be 512 bits long.
	If Elliptic Curve DH is used, the ECDH algorithm and key generation		If Elliptic Curve DH is used, the ECDH algorithm and key generation
	is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA		is from NIST SP 800-56A [SP800-56A]. The curves used are from NSA
	Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by		Suite B [NSA-Suite-B], which uses the same curves as ECDSA defined by
	FIPS 186-3 [FIPS-186-3], and can also be found in RFC 5114 [RFC5114],		FIPS 186-3 [FIPS-186-3], and can also be found in RFC 5114 section
	sections 2.6 through 2.8. ECDH test vectors may be found in RFC 5114		2.6 through 2.8 [RFC5114]. ECDH test vectors may be found in RFC
	[RFC5114], sections A.6 through A.8. The validation procedures are		5114 appendices A.6 through A.8 [RFC5114]. The validation procedures
	from NIST SP 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC		are from NIST SP 800-56A [SP800-56A] section 5.6.2.6, method 3, ECC
	Partial Validation. Both the X and Y coordinates of the point on the		Partial Validation. Both the X and Y coordinates of the point on the
	curve are sent, in the first and second half of the ECDH public		curve are sent, in the first and second half of the ECDH public
	value, respectively. The ECDH result returns only the X coordinate,		value, respectively. The ECDH result returns only the X coordinate,
	as specified in SP 800-56A. Useful strategies for implementing ECC		as specified in SP 800-56A. Useful strategies for implementing ECC
	may be found in [I-D.mcgrew-fundamental-ecc].		may be found in [I-D.mcgrew-fundamental-ecc].
	The choice of the negotiated hash algorithm (Section 5.1.2) is		The choice of the negotiated hash algorithm (Section 5.1.2) is
	coupled to the choice of key agreement type. If ECDH-384 (EC38) is		coupled to the choice of key agreement type. If ECDH-384 (EC38) is
	chosen as the key agreement, the negotiated hash algorithm MUST be		chosen as the key agreement, the negotiated hash algorithm MUST be
	either SHA-384, or the corresponding SHA-3 successor.		either SHA-384, or the corresponding SHA-3 successor.
	skipping to change at page 52, line 6		skipping to change at page 52, line 6
	SAS Type Block | Meaning		SAS Type Block | Meaning
	---------------------------------------------------		---------------------------------------------------
	"B32 " | Short Authentication String using		"B32 " | Short Authentication String using
	| base32 encoding		| base32 encoding
	---------------------------------------------------		---------------------------------------------------
	"B256" | Short Authentication String using		"B256" | Short Authentication String using
	| base256 encoding (PGP Word List)		| base256 encoding (PGP Word List)
	---------------------------------------------------		---------------------------------------------------
	Table 6. SAS Type Block Values		Table 6. SAS Type Block Values
	For the SAS Type of "B256", the leftmost 16 bits of the 32-bit		For the SAS Type of "B256", the most significant (leftmost) 16 bits
	sasvalue are rendered using the PGP Word List [pgpwordlist]		of the 32-bit sasvalue are rendered in network byte order using the
	[Juola1][Juola2].		PGP Word List [pgpwordlist] [Juola1][Juola2].
	For the SAS Type of "B32 ", the leftmost 20 bits of the 32-bit		For the SAS Type of "B32 ", the most significant (leftmost) 20 bits
	sasvalue are rendered as a form of base32 encoding, designed to		of the 32-bit sasvalue are rendered as a form of base32 encoding,
	represent bit sequences in a form that is convenient for human users		designed to represent bit sequences in a form that is convenient for
	to manipulate. The choice of characters and unusually permuted		human users to manipulate. The choice of characters and unusually
	ordering are explained in the source document for the encoding scheme		permuted ordering are explained in the source document for the
	[z-base-32], which differs from RFC 4648. The leftmost 20 bits of		encoding scheme [z-base-32], which differs from RFC 4648. The
	the sasvalue results in four base32 characters which are rendered to		leftmost 20 bits of the sasvalue results in four base32 characters
	both ZRTP endpoints. Here is a normative pseudocode implementation		which are rendered most significant quintet first to both ZRTP
	of the base32 function:		endpoints. Here is a normative pseudocode implementation of the
			base32 function:
	char[4] base32(uint32 bits)		char[4] base32(uint32 bits)
	{ int i, n, shift;		{ int i, n, shift;
	char result[4];		char result[4];
	for (i=0,shift=27; i!=4; ++i,shift-=5)		for (i=0,shift=27; i!=4; ++i,shift-=5)
	{ n = (bits>>shift) & 31;		{ n = (bits>>shift) & 31;
	result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n];		result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n];
	}		}
	return result;		return result;
	}		}
	skipping to change at page 52, line 43		skipping to change at page 52, line 44
	to sign the SAS as discussed in Section 7.2. The 4-octet Signature		to sign the SAS as discussed in Section 7.2. The 4-octet Signature
	Type Block, along with the accompanying signature block, are OPTIONAL		Type Block, along with the accompanying signature block, are OPTIONAL
	and may be present in the Confirm message (Figure 10) or the SASrelay		and may be present in the Confirm message (Figure 10) or the SASrelay
	message (Figure 16). The signature types are given in the table		message (Figure 16). The signature types are given in the table
	below.		below.
	Signature | Meaning		Signature | Meaning
	Type Block |		Type Block |
	------------------------------------------------		------------------------------------------------
	"PGP " | OpenPGP Signature, per RFC 4880		"PGP " | OpenPGP Signature, per RFC 4880
	| or I-D.jivsov-openpgp-ecc		|
	------------------------------------------------		------------------------------------------------
	"X509" | Suite B ECDSA, with X.509v3 cert		"X509" | Suite B ECDSA, with X.509v3 cert
	| per FIPS 186-3		| per FIPS 186-3
	------------------------------------------------		------------------------------------------------
	Table 7. Signature Type Block Values		Table 7. Signature Type Block Values
	Additional details on the signature and signing key format may be		Additional details on the signature and signing key format may be
	found in Section 7.2. OpenPGP signatures (Signature Type "PGP ") are		found in Section 7.2. OpenPGP signatures (Signature Type "PGP ") are
	discussed in Section 7.2.1. X.509v3 Suite B Signatures (Signature		discussed in Section 7.2.1. X.509v3 Suite B Signatures (Signature
	Type "X509") are discussed in Section 7.2.2.		Type "X509") are discussed in Section 7.2.2.
	Other signature types may be defined in a future document.		Other signature types may be defined in a future document.
	5.2. Hello message		5.2. Hello message
	The Hello message has the format shown in Figure 3.		The Hello message has the format shown in Figure 3.
	skipping to change at page 75, line 27		skipping to change at page 75, line 27
	The retry schedule must handle not only packet loss, but also slow or		The retry schedule must handle not only packet loss, but also slow or
	heavily loaded peers that need additional time to perform their DH		heavily loaded peers that need additional time to perform their DH
	calculations. The following mitigations are recommended:		calculations. The following mitigations are recommended:
	o Slow or heavily loaded ZRTP endpoints that are at risk of taking		o Slow or heavily loaded ZRTP endpoints that are at risk of taking
	too long to perform their DH calculation SHOULD use a HelloACK		too long to perform their DH calculation SHOULD use a HelloACK
	message instead of a Commit message to reply to a Hello from the		message instead of a Commit message to reply to a Hello from the
	other party.		other party.
	o If a ZRTP endpoint has evidence that the other party is a ZRTP		o If a ZRTP endpoint has evidence that the other party is a ZRTP
	endpoint, by receiving a Hello message or Ping message, it SHOULD		endpoint, by receiving a Hello message or Ping message, or by
	extend its own Hello retry schedule to span at least 12 seconds of		receiving a Hello hash in the signaling layer, it SHOULD extend
			its own Hello retry schedule to span at least 12 seconds of
	retries. If this extended Hello retry schedule is exhausted		retries. If this extended Hello retry schedule is exhausted
	without receiving a HelloACK or Commit message, a late Commit		without receiving a HelloACK or Commit message, a late Commit
	message from the peer SHOULD still be accepted.		message from the peer SHOULD still be accepted.
	These recommended retransmission intervals are designed for a typical		These recommended retransmission intervals are designed for a typical
	broadband Internet connection. In some high latency communication		broadband Internet connection. In some high latency communication
	channels, such as those provided by some mobile phone environments or		channels, such as those provided by some mobile phone environments or
	geostationary satellites, a different retransmission schedule may be		geostationary satellites, a different retransmission schedule may be
	used. The initial value for the T1 or T2 retransmission timer should		used. The initial value for the T1 or T2 retransmission timer should
	be increased to be no less than the round trip time provided by the		be increased to be no less than the round trip time provided by the
	skipping to change at page 79, line 19		skipping to change at page 79, line 19
	digital signature algorithm. For example, the sashash may be based		digital signature algorithm. For example, the sashash may be based
	on SHA-256, while the digital signature might use SHA-384, if an		on SHA-256, while the digital signature might use SHA-384, if an
	ECDSA P-384 key is used.		ECDSA P-384 key is used.
	If the ZRTP key exchange is ECDH, and the SAS is signed, then the		If the ZRTP key exchange is ECDH, and the SAS is signed, then the
	signature SHOULD be ECDSA, using the same size curve as the ECDH		signature SHOULD be ECDSA, using the same size curve as the ECDH
	exchange. NSA Suite B ECDSA algorithms may be used with either		exchange. NSA Suite B ECDSA algorithms may be used with either
	OpenPGP-formatted keys, or X.509v3 certificates.		OpenPGP-formatted keys, or X.509v3 certificates.
	If a ZRTP endpoint supports incoming signatures (evidenced by setting		If a ZRTP endpoint supports incoming signatures (evidenced by setting
	the (S) flag in the Hello message), it MUST be able to parse		the (S) flag in the Hello message), it SHOULD be able to parse
	signatures from the other endpoint in both formats (OpenPGP and		signatures from the other endpoint in OpenPGP format and MUST be able
	X.509v3). If the incoming signature is in an unsupported format, the		to parse them in X.509v3 format. If the incoming signature is in an
	ZRTP user agent SHOULD inform the user that the connection is not		unsupported format, or the trust model does not lead to a trusted
	known to be authenticated by a signature. The informed user may		introducer or a trusted CA, another authentication method may be used
	elect to proceed with the call at his discretion.		if available, such as the SAS compare, or a cached shared secret from
			a previous session. If none of these methods are available, it is up
			to the ZRTP user agent and the user to decide whether to proceed with
			the call, after the user is informed.
	ECDSA has a feature that allows most of the signature calculation to		Both ECDSA and DSA [FIPS-186-3] have a feature that allows most of
	be done in advance of the session, reducing latency during call		the signature calculation to be done in advance of the session,
	setup. This is useful for low power mobile handsets.		reducing latency during call setup. This is useful for low power
			mobile handsets.
	ECDSA is also preferred because it has compact keys and signatures.		ECDSA is preferred because it has compact keys as well as compact
	If the signature along with its public key certificate are		signatures. If the signature along with its public key certificate
	insufficiently compact, the Confirm message may become too long for		are insufficiently compact, the Confirm message may become too long
	the maximum transmission unit (MTU) size, and UDP fragmenation may		for the maximum transmission unit (MTU) size, and UDP fragmenation
	result. Some firewalls and NATs may discard fragmented UDP packets,		may result. Some firewalls and NATs may discard fragmented UDP
	which would cause the ZRTP exchange to fail. It is RECOMMENDED that		packets, which would cause the ZRTP exchange to fail. It is
	a ZRTP endpoint avoid sending signatures if they would cause UDP		RECOMMENDED that a ZRTP endpoint avoid sending signatures if they
	fragmentation. For a discussion on MTU size and PMTU discovery, see		would cause UDP fragmentation. For a discussion on MTU size and PMTU
	[RFC1191] and [RFC1981].		discovery, see [RFC1191] and [RFC1981].
			From a packet size perspective, ECDSA and DSA both produce equally
			compact signatures for a given signature strength. DSA keys are much
			bigger than ECDSA keys, but in the case of OpenPGP signatures, the
			public key is not sent along with the signature.
	7.2.1. OpenPGP Signatures		7.2.1. OpenPGP Signatures
	If the SAS Signature Type (Section 5.1.7) specifies an OpenPGP		If the SAS Signature Type (Section 5.1.7) specifies an OpenPGP
	signature ("PGP "), the signature-related fields are arranged as		signature ("PGP "), the signature-related fields are arranged as
	follows.		follows.
	The first field after the 4-octet Signature Type Block is the OpenPGP		The first field after the 4-octet Signature Type Block is the OpenPGP
	signature. The format of this signature and the algorithms that		signature. The format of this signature and the algorithms that
	create it are specified by [RFC4880] or [I-D.jivsov-openpgp-ecc].		create it are specified by [RFC4880]. The signature is comprised of
	The signature is comprised of a complete OpenPGP version 4 signature		a complete OpenPGP version 4 signature in binary form (not Radix-64),
	in binary form (not Radix-64), as specified in RFC 4880, section		as specified in RFC 4880 section 5.2.3, enclosed in the full OpenPGP
	5.2.3, enclosed in the full OpenPGP packet syntax. The length of the		packet syntax. The length of the OpenPGP signature is parseable from
	OpenPGP signature is parseable from the signature, and depends on the		the signature, and depends on the type and length of the signing key.
	type and length of the signing key.
	If OpenPGP signatures are supported, an implementation SHOULD NOT		If OpenPGP signatures are supported, an implementation SHOULD NOT
	generate signatures using any other signature algorithm except DSA or		generate signatures using any other signature algorithm except DSA or
	ECDSA, but MAY accept other signature types from the other party.		ECDSA (ECDSA is a reserved algorithm type in RFC 4880), but MAY
	DSA signatures with keys shorter than 2048 bits or longer than 3072		accept other signature types from the other party. DSA signatures
	bits MUST NOT be generated. An implementation MUST use only NIST-		with keys shorter than 2048 bits or longer than 3072 bits MUST NOT be
	approved hash algorithms in signatures, and MUST NOT use SHA1 in the		generated. An implementation MUST use only NIST-approved hash
	signature. NIST-approved hash algorithms are found in [FIPS-180-3]		algorithms in signatures, and MUST NOT use SHA1 in the signature.
	or its SHA-3 successor. ECDSA OpenPGP signatures are specified in		NIST-approved hash algorithms are found in [FIPS-180-3] or its SHA-3
	[I-D.jivsov-openpgp-ecc]. Signatures with ECDSA keys larger than		successor.
	P-384 or smaller than P-224 SHOULD NOT be generated.
			Implementors should be aware that ECDSA signatures for OpenPGP are
			expected to become available when the work-in-progress
			[I-D.jivsov-openpgp-ecc] becomes an RFC. Any use of ECDSA signatures
			in ZRTP SHOULD NOT generate signatures using ECDSA key sizes other
			than P-224, P-256, and P-384, as defined in [FIPS-186-3]. Note that
			Suite B compliance in Section 7.2.2 would additionally exclude P-224
			from X.509v3 signatures.
	RFC 4880 section 5.2.3.18 specifies a way to embed, in an OpenPGP		RFC 4880 section 5.2.3.18 specifies a way to embed, in an OpenPGP
	signature, a URI of the preferred key server. The URI should be		signature, a URI of the preferred key server. The URI should be
	fully specified to obtain the public key of the signing key that		fully specified to obtain the public key of the signing key that
	created the signature. This URI MUST be present.		created the signature. This URI MUST be present. It is up to the
			recipient of the signature to obtain the public key of the signing
	It is up to the recipient of the signature to obtain the public key		key and determine its validity status using the OpenPGP trust model
	of the signing key and determine its validity status using the		discussed in [RFC4880].
	OpenPGP trust model discussed in [RFC4880].
	The contents of Figure 20 lie inside the encrypted region of the		The contents of Figure 20 lie inside the encrypted region of the
	Confirm message (Figure 10) or the SASrelay message (Figure 16).		Confirm message (Figure 10) or the SASrelay message (Figure 16).
	The total length of all the material in Figure 20, including the key		The total length of all the material in Figure 20, including the key
	server URI, must not exceed 511 32-bit words (2044 octets). This		server URI, must not exceed 511 32-bit words (2044 octets). This
	length, in words, is stored in the signature length field in the		length, in words, is stored in the signature length field in the
	Confirm or SASrelay message containing the signature. It is		Confirm or SASrelay message containing the signature. It is
	desirable to avoid UDP fragmentation, so the URI should be kept		desirable to avoid UDP fragmentation, so the URI should be kept
	short.		short.
	skipping to change at page 87, line 46		skipping to change at page 87, line 52
	The ABNF for the ZRTP attribute is as follows:		The ABNF for the ZRTP attribute is as follows:
	zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value		zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
	zrtp-version = token		zrtp-version = token
	zrtp-hash-value = 1*(HEXDIG)		zrtp-hash-value = 1*(HEXDIG)
	Here's an example of the ZRTP attribute in an initial SDP offer or		Here's an example of the ZRTP attribute in an initial SDP offer or
	answer used at the media level, using the <allOneLine> convention		answer used at the media level, using the <allOneLine> convention
	defined in RFC 4475, section 2.1 [RFC4475]:		defined in RFC 4475 section 2.1 [RFC4475]:
	v=0		v=0
	o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com		o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
	s=		s=
	c=IN IP4 client.biloxi.example.com		c=IN IP4 client.biloxi.example.com
	t=0 0		t=0 0
	m=audio 3456 RTP/AVP 97 33		m=audio 3456 RTP/AVP 97 33
	a=rtpmap:97 iLBC/8000		a=rtpmap:97 iLBC/8000
	a=rtpmap:33 no-op/8000		a=rtpmap:33 no-op/8000
	<allOneLine>		<allOneLine>
	skipping to change at page 107, line 28		skipping to change at page 107, line 28
	[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and		[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and
	Certificate Revocation List (CRL) Profile", RFC 5759,		Certificate Revocation List (CRL) Profile", RFC 5759,
	January 2010.		January 2010.
	[I-D.ietf-avt-srtp-big-aes]		[I-D.ietf-avt-srtp-big-aes]
	McGrew, D., "The use of AES-192 and AES-256 in Secure		McGrew, D., "The use of AES-192 and AES-256 in Secure
	RTP",		RTP",
	http://tools.ietf.org/html/draft-ietf-avt-srtp-big-aes .		http://tools.ietf.org/html/draft-ietf-avt-srtp-big-aes .
	[I-D.jivsov-openpgp-ecc]
	Jivsov, A., "ECC in OpenPGP",
	http://tools.ietf.org/html/draft-jivsov-openpgp-ecc .
	[FIPS-140-2-Annex-A]		[FIPS-140-2-Annex-A]
	"Annex A: Approved Security Functions for FIPS PUB 140-2",		"Annex A: Approved Security Functions for FIPS PUB 140-2",
	NIST FIPS PUB 140-2 Annex A October 2008.		NIST FIPS PUB 140-2 Annex A October 2008.
	[FIPS-140-2-Annex-D]		[FIPS-140-2-Annex-D]
	"Annex D: Approved Key Establishment Techniques for FIPS		"Annex D: Approved Key Establishment Techniques for FIPS
	PUB 140-2", NIST FIPS PUB 140-2 Annex D January 2008.		PUB 140-2", NIST FIPS PUB 140-2 Annex D January 2008.
	[FIPS-180-3]		[FIPS-180-3]
	"Secure Hash Standard (SHS)", NIST FIPS PUB 180-3 October		"Secure Hash Standard (SHS)", NIST FIPS PUB 180-3 October
	skipping to change at page 110, line 18		skipping to change at page 110, line 12
	Traversal for Offer/Answer Protocols", RFC 5245,		Traversal for Offer/Answer Protocols", RFC 5245,
	April 2010.		April 2010.
	[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, May 2010.		Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869, May 2010.		Key Derivation Function (HKDF)", RFC 5869, May 2010.
			[I-D.jivsov-openpgp-ecc]
			Jivsov, A., "ECC in OpenPGP",
			http://tools.ietf.org/html/draft-jivsov-openpgp-ecc .
	[I-D.perkins-avt-srtp-vbr-audio]		[I-D.perkins-avt-srtp-vbr-audio]
	Perkins, C. and J. Valin, "Guidelines for the use of		Perkins, C. and J. Valin, "Guidelines for the use of
	Variable Bit Rate Audio with Secure RTP", http://		Variable Bit Rate Audio with Secure RTP", http://
	tools.ietf.org/html/draft-perkins-avt-srtp-vbr-audio .		tools.ietf.org/html/draft-perkins-avt-srtp-vbr-audio .
	[I-D.wing-sip-identity-media]		[I-D.wing-sip-identity-media]
	Wing, D. and H. Kaplan, "SIP Identity using Media Path",		Wing, D. and H. Kaplan, "SIP Identity using Media Path",
	http://tools.ietf.org/html/draft-wing-sip-identity-media .		http://tools.ietf.org/html/draft-wing-sip-identity-media .
	[I-D.mcgrew-fundamental-ecc]		[I-D.mcgrew-fundamental-ecc]
End of changes. 22 change blocks.
	68 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/