Network Working Group M. Baugher
Internet-Draft D. McGrew
Expires: August 28, 2006 Cisco Systems, Inc.
February 24, 2006
Diffie-Hellman Exchanges for Multimedia Sessions
draft-baugher-mmusic-sdp-dh-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines a new Session Description Protocol (SDP) attribute
for exchanging Diffie-Hellman (DH) public keys. The attribute is an
SDP session-level attribute for describing DH keys, and there is a
new media-level parameter for describing public keying material for
SRTP key generation. The SDP attribute supports the key
establishment schemes of NIST Draft Special Publication 800-56, adds
domain parameters and supports external authentication of the DH
endpoint without a public key infrastructure.
Baugher & McGrew Expires August 28, 2006 [Page 1]
Internet-Draft SDP-DH February 2006
Table of Contents
1. Introduction: SDP Discrete Logarithm Cryptography (DLC) . . . 3
1.1. Attacks and Protections . . . . . . . . . . . . . . . . . 3
1.2. Overview of This Document . . . . . . . . . . . . . . . . 5
1.3. Conformance Language . . . . . . . . . . . . . . . . . . . 6
2. The SDP DH Attribute and Parameters . . . . . . . . . . . . . 7
2.1. Mandatory DLC Suite: Stat_FFCDH_Group_2 . . . . . . . . . 7
2.1.1. IKE Group 2 Domain Parameters . . . . . . . . . . . . 8
2.1.2. Encoding of the DHkey Parameter . . . . . . . . . . . 8
2.1.3. Computation of the Shared Secret . . . . . . . . . . . 9
2.2. The Stat_ECDH_Group_19 DLC Suite . . . . . . . . . . . . . 9
2.2.1. IKE Group 19 Domain Parameters . . . . . . . . . . . . 10
2.2.2. DHkey Parameter Encoding . . . . . . . . . . . . . . . 10
2.2.3. Computation of the Shared Secret . . . . . . . . . . . 11
2.3. The Ephem_ECDH_Group_19 DLC Suite . . . . . . . . . . . . 11
2.3.1. IKE Group 19 Domain Parameters . . . . . . . . . . . . 11
2.3.2. DHkey Parameter Encoding . . . . . . . . . . . . . . . 11
2.3.3. Computation of the Shared Secret . . . . . . . . . . . 11
2.4. The Stat_FFDH_Group_14 DLC Suite . . . . . . . . . . . . . 11
2.4.1. IKE Group 14 Domain Parameters . . . . . . . . . . . . 12
2.4.2. DHkey Parameter Encoding . . . . . . . . . . . . . . . 12
2.4.3. Computation of the Shared Secret . . . . . . . . . . . 12
2.5. The Ephem_FFDH_Group_14 DLC Suite . . . . . . . . . . . . 13
2.5.1. IKE Group 14 Domain Parameters . . . . . . . . . . . . 13
2.5.2. DHkey Parameter Encoding . . . . . . . . . . . . . . . 13
2.5.3. Computation of the Shared Secret . . . . . . . . . . . 13
2.6. ABNF Grammar for DH Attribute and DLC_Suites . . . . . . . 13
2.7. Offer/Answer Processing . . . . . . . . . . . . . . . . . 14
2.8. Adding New DH Suites . . . . . . . . . . . . . . . . . . . 15
3. The "nonce" DH Parameter . . . . . . . . . . . . . . . . . . . 16
3.1. Changes to RFC {sdesc} "crypto" Grammar . . . . . . . . . 16
3.2. Generating SRTP Master Keys from Public Information . . . 18
3.3. Media-session Key Derivation . . . . . . . . . . . . . . . 18
3.4. Offer/Answer Processing . . . . . . . . . . . . . . . . . 19
4. Person-to-Person Authentication . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 21
5.2. Bid-down Attack . . . . . . . . . . . . . . . . . . . . . 22
5.3. Ephemeral and Static Keys . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Baugher & McGrew Expires August 28, 2006 [Page 2]
Internet-Draft SDP-DH February 2006
1. Introduction: SDP Discrete Logarithm Cryptography (DLC)
RFC {sdesc} allows keys and parameters to be signaled in Session
Description Protocol (SDP) by a media-level attribute. Called
"crypto", this attribute establishes keys between endpoints and
defines "crypto suites" for SRTP [sdesc]. However, RFC {sdesc}
currently uses only symmetric cryptography and lacks a public key
mechanism such as a Diffie-Hellman (DH) key exchange. This document
adds a DH exchange to SDP to improve security in several ways.
1. It eliminates the need to trust the signaling devices (e.g. SIP
proxies).
2. It reduces or eliminates the need for public-key infrastructure,
as is needed when protecting RFC {sdesc} symmetric keys with
S/MIME [RFC3851].
3. It provides better security in the presence of forked signaling.
4. It can provide perfect forward secrecy to media keys.
To these ends, DH offers several advantages over RFC {sdesc} methods.
When SIP forking occurs[RFC3261], RFC {sdesc} can potentially reveal
the key to an untrusted party on one of the forked devices. For
example, a phone call may be forked to an executive and a
receptionist. If the SDP crypto attribute contains a symmetric key,
the receptionist is given enough information to perpetrate a passive
eavesdropping attack on the caller. In contrast, an SDP Diffie-
Hellman exchange (SDP-DH) provides a shared secret between the caller
and each of the forked endpoints. With SDP-DH, the receptionist in
our example would only know the public DH value of the caller and
would not be able to perpetrate an attack.
1.1. Attacks and Protections
To prevent attacks during forking or any SDP message exchange, RFC
{sdesc} has a stringent and challenging requirement: The SDP message
needs end-to-end security when it contains a crypto attribute on any
of its media lines. This attribute and its parameters may be secured
end-to-end by S/MIME or by an end-to-end data security protocol such
as TLS. These mechanisms are easy to provide in some situations,
such as when all of the devices that handle the signaling are within
a single trust domain. However, SIP generally does not have end-to-
end transport connections between caller and callee, but uses SIPS
for transport-level security. SIPS is a set of hop-by-hop TLS
connections. There are no verifiable guarantees about the security
at SIP hops that have access to the SIP message during forwarding.
And, lacking the end-to-end integrity protection afforded by S/MIME,
Baugher & McGrew Expires August 28, 2006 [Page 3]
Internet-Draft SDP-DH February 2006
the crypto attribute is vulnerable to both passive and active attacks
by systems in the middle. An SDP Diffie-Hellman exchange provides an
alternative to hop-by-hop transport security without requiring a
public key infrastructure or S/MIME.
When the signaling message contains a DH key, it is sufficient to
provide authentication without confidentiality on signaling traffic.
The level of trust in the devices that handle the plaintext SDP
message is reduced, since knowledge of the DH public key does not
allow those devices to perform a passive eavesdropping attack.
Certain devices in the signaling path can perform an active attack in
the absence of end-to-end authentication. An active attack can
happen when the attacker intercepts both signaling and media messages
between the media endpoints and is able to decrypt, eavesdrop, and
re-encrypt the media. However, the active attack is considerably
more difficult than a passive attack.
Several existing methods can provide complete protection against
active attacks. In cases where the signaling system is trusted to
identify an endpoint's public key, the SIP Identity service
[SIPidentity] can be used to authenticate the DH public keys. SIP
Identity authenticates the SDP message so long as the phone users
trust the SIP Identity provider. When properly authenticated by such
means, SDP-DH establishes a pair-wise secret at each endpoint, and
has no vulnerability to active attacks. When SIP Identity is
unavailable, or when it is undesirable to trust that mechanism, it is
possible to provide person-to-person authentication on the DH key
strictly between the media endpoints. This method is used by the
AT&T secure phone [Schneier], for example. In it, one person reads a
fingerprint (hash) of the shared secret and the other person checks
it against their hash. Following the process of checking a hash of
the DH shared secret, each user can cache information about the
public keys, allowing them to construct a "personal PKI" that is
analogous to a PGP key ring [Zimmermann].
Finally, SDP-DH can provide perfect forward secrecy [DVW] to the
cryptographic keys of SDP media sessions. This method protects
recorded media sessions against future disclosure of either
endpoint's private keys for ephemeral DH public keys. The media-
stream key cannot be recovered so long as the ephemeral DH keying
material that generated the secret is maintained according Section
5.6.4 of the Draft Recommendation [NIST-800-56].
Nonetheless, there are significant performance advantages to static
keys over ephemeral keys for applications that wish to trade the
benefits of perfect forward secrecy for the lower computational
overhead that comes from reusing public-keys across multiple
multimedia sessions. This memo therefore allows for both ephemeral
Baugher & McGrew Expires August 28, 2006 [Page 4]
Internet-Draft SDP-DH February 2006
and static Diffie-Hellman key management schemes. A DH public key
MAY be ephemeral or static.
To add Diffie-Hellman public keys to SDP messages, this memo
introduces a new security attribute that is called "DH", which
appears at the SDP session level. To allow SRTP to derive keys from
the DH shared secret, this document defines a new media-level
security parameter called "nonce", which carries public data for use
in generating a pair-wise secret for the SRTP master key; the public
data are salt, a nonce, optional key lifetime and optional SRTP
master key index. The DH attribute and nonce parameter provide a
framework for putting Diffie-Hellman key exchange protocols into SDP.
Definitions are provided for IETF-standard Elliptic Curve
Cryptography (ECC) [FS] and integer-based Finite Field Cryptography
(FFC) [RFC3526][RFC4306]. An example DH attribute that uses a
STAT_FFDH_Group_19 "DH suite", a DH dhkey parameter, and the media-
level nonce parameter are shown in Figure 1.
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
a=DH: STAT_ECDH_GROUP_19
dhkey: 2tC2U5QiHPmwUeH+yleH0Jjf5jf8kLnvlF0MN3JYEYA=
UnGgRhzbglLWHxxFb6PlmrH0WzOsz19YOJ4Fd7iZC7M=
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
nonce:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
Figure 1: Example DH attribute and parameters.
1.2. Overview of This Document
Section 2 defines the SDP DH attribute shown in Figure 1 and it
defines public key ("dhkey") encodings, offer/answer processing, and
the SDP-DH grammar in Augmented Backus-Naur form (ABNF). Section 3
applies DH to the RFC{sdesc} media-level crypto attribute and gives
the ABNF of a new crypto parameter called "nonce" (also shown in
Figure 1) for generating media keys. The new parameter uses the
output of SDP DH for input into SRTP master key generation according
to Section 3. Section 4 defines a hash for person-to-person
authentication. The Security Considerations of Section 5 discusses
attacks and protections for DH suites, and Section 6 states the
Baugher & McGrew Expires August 28, 2006 [Page 5]
Internet-Draft SDP-DH February 2006
requirements on IANA for the SDP DH attribute and the parameters
defined herein.
1.3. Conformance Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Baugher & McGrew Expires August 28, 2006 [Page 6]
Internet-Draft SDP-DH February 2006
2. The SDP DH Attribute and Parameters
The SDP DH attribute has a discrete logarithm cryptography suite of
parameters (DH suite) and an encoding of one public key. As shown in
Figure 1, DH is an SDP session-level attribute whereas crypto is at
the media level. The DH attribute applies to a multimedia session
and the crypto nonce parameter applies to a single media session.
The reason that the DH attribute operates at the SDP session level is
to allow the computationally expensive DH exchange to be used across
multiple media streams.
An SDP Offer/Answer exchange [RFC3264] SHALL be the default method of
exchanging DH parameters between endpoints that compute a shared DH
secret. SRTP key generation SHALL use the DH shared secret and
public keying material. This exchange of DH public keys and keying
material MUST be externally authenticated between the two parties.
The authentication MAY be a person-to-person procedure or MAY use SIP
Identity as described in the Security Considerations section.
The SDP DH attribute is a framework to support Diffie-Hellman key
establishment "schemes" [NIST-800-56]. This document REQUIRES one
key-establishment scheme as the basis for interoperability, however,
and that is a static, Finite Field Cryptography (FFC) scheme.
Stat_FFDH_Group_2 is the DH-suite name for the mandatory scheme.
Stat_FFDH_Group_2 uses domain parameters from the IKEv2 MODP Group 2
[RFC4306]. Implementations of this specification MUST support at
least the static FFC scheme. Note that an ephemeral FFC scheme can
be implicitly supported with a static public key that is used exactly
once. The key is more than nominally static, therefore, when it is
reused over multiple multimedia sessions from a cache of public keys
and shared secrets. Use of static keys trades perfect forward
secrecy for savings in exponentiations and user effort, particularly
when the user effort is an external person-to-person authentication
"ceremony" [WE] or a check of SIP Identity. Applications that desire
PFS MAY choose an ephemeral DH suite or MAY use a static public key
only once.
The SDP DH attribute has two parameters, a "DH suite" and "dhkey".
1. A DH suite declares the key management scheme and parameters.
2. dhkey encodes a cryptographic key for the DH suite.
SDP DH has one output, the DH shared secret.
2.1. Mandatory DLC Suite: Stat_FFCDH_Group_2
In choosing a common DH suite for maximal interoperability, there are
Baugher & McGrew Expires August 28, 2006 [Page 7]
Internet-Draft SDP-DH February 2006
trade offs in security, efficiency of computation, compactness of
signaling parameters as well as known Intellectual Property Rights
(IPR) claims. For Session Description Protocol signaling,
compactness is a compelling requirement. From this perspective, the
Elliptic Curve Cryptography Diffie-Hellman (ECC-DH) suites are
attractive. But there are known IPR claims on ECC.
The Finite Field Cryptography (FFC) DH suites are without known IPR
claims. The smallest group size acceptable to the Draft
Recommendation is 1024 bits and this is chosen as the "Mandatory" DH
suite, which is mandatory to implement but not mandatory to use. It
is mandatory to implement so as to foster interoperable
implementations that can always communicate using SDP DH. But the
cryptographic strength of the 1024-bit DH Suite (Stat_FFCDH_Group_2)
might be too weak for certain applications who MAY reject use of this
suite in SDP DH offers.
Stat_FFCDH_Group_2 is based upon the "dhStatic" scheme of Table 5 in
the Draft Recommendation [NIST-800-56].
2.1.1. IKE Group 2 Domain Parameters
The public key for Stat_FFCDH_Group_2 is a big integer that is 1024
bits in length and defined in IKEv2 [RFC4306]. The big prime integer
field IKEv2 MODP Group 2 is quoted and copied below for the
convenience of the reader. See the discussion in Appendix E of RFC
2412 for a description of how the primes were generated and
suggestions on efficient implementations [RFC2412].
"This group is assigned id 2 (two).
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE65381 FFFFFFFF FFFFFFFF
The generator is 2."
2.1.2. Encoding of the DHkey Parameter
An example DH attribute is shown below, the STAT_FFDH_GROUP_2 DH
suite name string is followed by an example dhkey parameter.
Baugher & McGrew Expires August 28, 2006 [Page 8]
Internet-Draft SDP-DH February 2006
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127
t=2873397496 2873404696
a=DH: STAT_FFDH_GROUP_2
dhkey:
f3kHGsXFPDWlPU7/9Vn+Elcb32j7X5xRVVbWZVN9xaTq9v0MiKCovTwVA6K/17SW0
P3BrY3lGmkhJHRbmuqiurPLCBDGYqUdl8HLPlqX0Jd9qYJ58ILszdSgyrjnQzrLGu
lgHoOQXeZef8SGEXY5qtaugNSg57Qxdn4e1MJQpAk=
m=video 51372 RTP/SAVP 31
a=crypto:1 AES_CM_128_HMAC_SHA1_80
nonce:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
nonce:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
m=application 32416 udp wb
a=orient:portrait
Figure 3: Example STAT_FFDH_Group_2 DLC Suite
An ABNF grammar for the DH attribute and dhkey parameter is given in
the Grammar Section below. Stat_FFCDH_Group_2 has a public key value
that is 172 bytes long when it is base-64 encoded. Some applications
that use SDP over User Datagram Protocol (UDP) might have a problem
with such a large field. The ECC DH suites have a much shorter
public key and are described below.
2.1.3. Computation of the Shared Secret
Computation of the shared secret value Z for this DH suite is defined
in Section 5.7.1.1 of the Draft Recommendation[NIST-800-56].
2.2. The Stat_ECDH_Group_19 DLC Suite
The Stat_ECDH_Group_19 key establishment scheme is based upon the
"Cofactor Static Unified Model" of Table 5 in the Draft
Recommendation [NIST-800-56]. This scheme uses two static keys, one
at the offerer and one at the answerer but no ephemeral keys.
"Stat_ECDH_Group_19_SHA256" is an alternative designation since SHA-
256 [FIPS-180-2] is the hash function used by this DH Suite. But
SHA-256 is mandated for this key establishment scheme by Table 2 of
the Draft Recommendation, and so "SHA256" is redundant. Furthermore,
the "Group_19" in the DH Suite name is based on IKE Group 19, which
Baugher & McGrew Expires August 28, 2006 [Page 9]
Internet-Draft SDP-DH February 2006
is an Elliptic Curve Diffie-Hellman based on the nineteenth IKE
group.
2.2.1. IKE Group 19 Domain Parameters
Stat_ECDH_Group_19 SHALL use the IKE Group 19 domain parameters. For
the convenience of reader, the definition of the nineteenth IKE group
is reproduced below [FS].
"The curve is based on the integers modulo the generalized Mersenne
prime p given by
p = 2^(256)-2^(224)+2^(192)+2^(96)-1.
The equation for the elliptic curve is: y^2 = x^3 - 3 x + b.
Field size: 256
Group Prime/Irreducible Polynomial:
FFFFFFFF 00000001 00000000 00000000
00000000 FFFFFFFF FFFFFFFF FFFFFFFF
Group Curve b:
5AC635D8 AA3A93E7 B3EBBD55 769886BC
651D06B0 CC53B0F6 3BCE3C3E 27D2604B
Group order:
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
BCE6FAAD A7179E84 F3B9CAC2 FC632551
The group was chosen verifiably at random using SHA-1 as specified in
IEEE P1363 [IEEE-1363] from the seed:
C49D3608 86E70493 6A6678E1 139D26B7 819F7E90
The generator for this group is given by g=(gx,gy) where
gx: 6B17D1F2 E12C4247 F8BCE6E5 63A440F2
77037D81 2DEB33A0 F4A13945 D898C296
gy: 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
2BCE3357 6B315ECE CBB64068 37BF51F5"
2.2.2. DHkey Parameter Encoding
The public key for Stat_ECDH_Group_19 is a point on an elliptic
curve, which is encoded in the SDP DH "dhkey" parameter. An example
of a Stat_ECDH_Group_19 DH suite is shown in Figure 1.
Baugher & McGrew Expires August 28, 2006 [Page 10]
Internet-Draft SDP-DH February 2006
The data in the dhkey parameter of Figure 1 is a point with an x
coordinate (gx) followed by a y coordinate (gy) and encoded in base
64. This is given in Augmented Backus-Naur form in the grammar
section of this document. The dhkey value is shown in Figure 1 as a
pair of base-64 encoded values that follow "dhkey:". These sum to 88
bytes in length. Also shown in the figure is a new parameter for
crypto called "nonce", which uses the DH secret in deriving an SRTP
master key. DHkey is defined in a later section.
2.2.3. Computation of the Shared Secret
Computation of the Diffie-Hellman shared secret, Z, for this DH suite
is defined in Section 5.7.1.2 of the Draft Recommendation
[NIST-800-56].
2.3. The Ephem_ECDH_Group_19 DLC Suite
The Ephem_ECDH_Group_19 key establishment scheme is based upon the
Cofactor Ephemeral Unified Model of Table 5 in the Draft
Recommendation [NIST-800-56]. This scheme uses two ephemeral keys
and no static keys.
2.3.1. IKE Group 19 Domain Parameters
Ephem_ECDH_Group_19 SHALL use the IKE Group 19 domain parameters.
For the convenience of reader, the definition of the nineteenth IKE
group is reproduced in the Stat_ECDH_Group_19 section above.
2.3.2. DHkey Parameter Encoding
The public key for Ephem_ECDH_Group_19 is a point on an elliptic
curve, which is encoded in an SDP DH parameter called "dhkey". The
dhkey parameter encoding for Ephem_ECDH_Group_19 is identical to that
of the Stat_ECDH_Group_19 given above. The Ephem_ECDH_Group_19
grammar is given in the Grammar section below.
2.3.3. Computation of the Shared Secret
Computation of the Diffie-Hellman shared secret, Z, for this DH suite
is defined in Section 5.7.1.2 of the Draft Recommendation
[NIST-800-56].
2.4. The Stat_FFDH_Group_14 DLC Suite
This section defines a Finite Field Cryptography (FFC) exchange,
"Stat_FFDH_Group_14." This key management scheme uses (only) pair-
wise static keys and no ephemeral keys. Stat_FFDH_Group_14 is based
upon the "dhStatic" scheme of Table 5 in the Draft Recommendation
Baugher & McGrew Expires August 28, 2006 [Page 11]
Internet-Draft SDP-DH February 2006
[NIST-800-56] as well as X.9 and IEEE P1363 [IEEE1363]. This memo
defines Stat_FFDH_Group_14 to use the IKE Group 14 domain parameters
[RFC3526].
2.4.1. IKE Group 14 Domain Parameters
For the convenience of the reader, the IKE Group 14 definition is
copied from the standard [RFC3526] below.
"This group is assigned id 14. This prime is:
2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
The generator is: 2."
2.4.2. DHkey Parameter Encoding
The dhkey for a Stat_FFDH_Group_14 public key is a 2048 byte integer
that is base-64 encoded as shown in the example below.
dhkey: ///////////JD9qiIWjCNMTGYouA3BzRKQJOCIpnzHQCC76mO
xObIlFKCHmONATd75UZs806QxswKwpt8l8UN0/hNW1tUcJF5IW1dmJefsb0T
ELppjftawv/XLb0Brft7jhr+1qJn6WunyQRfEsf5kkoZlHs5Fs9wgB8uKFjv
wWY2kg2HFXTmmkWP6j9JM9fg2VdI9yjrZYcYvNWIIVSu57VKQdwlpZtZww1T
kq8mATxdGwIyhghfDKQXkYuNs474553LBgOhgObJ4Oi7Aeij7XFXfBvTFLJ3
ivL9pVYFxg5lUl86pVq5RXSJhiY+gUQFXKOWoqsqmj//////////w==
An ABNF grammar for Stat_FFDH_Group_14 is given in the Grammar
section of this document.
2.4.3. Computation of the Shared Secret
Computation of the Diffie-Hellman shared secret, Z, for this DH suite
is defined in Section 5.7.1.1 of the Draft Recommendation
[NIST-800-56].
Baugher & McGrew Expires August 28, 2006 [Page 12]
Internet-Draft SDP-DH February 2006
2.5. The Ephem_FFDH_Group_14 DLC Suite
This section defines a Finite Field Cryptography (FFC) exchange,
"Ephem_FFDH_Group_14." This key management scheme uses (only) pair-
wise ephemeral keys and no static keys. Ephem_FFDH_Group_14 is based
upon the "dhEphem" of the Draft Recommendation [NIST-800-56] as well
as X.9 and IEEE P1363 [IEEE1363].
2.5.1. IKE Group 14 Domain Parameters
Ephem_FFDH_Group_14 SHALL use the IKE Group 14 domain parameters
[RFC3526]. For the convenience of the reader, the IKE Group 14
definition is given in the Stat_FFDH_Group_14 section above.
2.5.2. DHkey Parameter Encoding
The dhkey for an Ephem_FFDH_Group_14 public key is a 2048 byte
integer that is base-64 encoded. The encoding for
Ephem_FFDH_Group_14 encoding is identical to that of
Stat_FFDH_Group_14 and is shown in the section above. An ABNF
grammar for Ephem_FFDH_Group_14 is given in the Grammar section of
this document.
2.5.3. Computation of the Shared Secret
Computation of the Diffie-Hellman shared secret, Z, for this DH suite
is defined in Section 5.7.1.1 of the Draft Recommendation
[NIST-800-56].
2.6. ABNF Grammar for DH Attribute and DLC_Suites
Baugher & McGrew Expires August 28, 2006 [Page 13]
Internet-Draft SDP-DH February 2006
"a=DH:" [tag] dlc-suite
tag = *WSP 1*9DIGIT
dlc-suite = 1*WSP ( Stat_FFDH_Group_2 /
Stat_ECDH_Group_19 /
Stat_FFDH_Group_14 /
Ephem_ECDH_Group_19 /
Ephem_FFDH_Group_14 )
Stat_FFDH_Group_2 = "Stat_ECDH_Group_2" 1*LWSP "dhkey:" GexpX
Stat_ECDH_Group_19 = "Stat_ECDH_Group_19" 1*LWSP "dhkey:" gx gy
Stat_FFDH_Group_14 = "Stat_FFDH_Group_14" 1*LWSP "dhkey:" GexpW
Ephem_ECDH_Group_19 = "Ephem_ECDH_Group_19" 1*LWSP "dhkey:" gx gy
Ephem_FFDH_Group_14 = "Ephem_FFDH_Group_14" 1*LWSP "dhkey:" GexpW
gx = *LWSP 44(BASE64)
gy = 1*LWSP 44(BASE64)
GexpX = 172( *LWSP BASE64 )
GexpW = 344( *LWSP BASE64 )
BASE64 = %x21-3A / %x3C-7E ; base-64 character set
NOTES:
1. Gexp* is G^o in the offer where o is the offerer's private key.
2. Gexp* is G^a in the answer where a is the answerer's private key.
3. WSP, LWSP, ALPHA, DIGIT and ABNF grammar are from RFC 4234.
Figure 7: SDP DH Grammar
2.7. Offer/Answer Processing
An Offerer who uses a DH attribute in an SDP message MUST number that
attribute if it is one offer among multiple offers. An Offerer
SHOULD NOT number the DH attribute if there is only one offer but an
answerer MUST accept a single offer that has a tag and use that tag
in a successful reply. Each numbered offer MUST have a unique tag
from the other SDP DH offers. Each offer MUST differ in at least one
other parameter from the other offers.
Upon receipt of a single offer, the answerer SHALL accept or reject
the message according to the answerer's security policy for
processing DH. An implementation's security policy MAY allow ECDH or
not, for example. Or a policy MAY choose to use only ephemeral keys.
An answerer that does not recognize an SDP DH attribute will of
course ignore it [RFC2327], and there will be no DH attribute in the
answer. In this case, the offerer MUST abort the offer/answer
exchange. When it cannot accept an offer, the answerer MAY return a
Baugher & McGrew Expires August 28, 2006 [Page 14]
Internet-Draft SDP-DH February 2006
DH suite that it will accept as a hint in its answer. The offerer
MAY choose to re-run the SDP offer/answer exchange if the alternative
DH suite is within its security policy but MUST NOT re-run the
exchange if the answerer's DH suite "bids down" its minimum
acceptable policy (see the "Security Considerations" below).
Upon receipt of multiple offers, the answerer SHALL accept one offer
according to its security policy or it MUST reject all offers. A
selected offer MUST have the same tag value in the answerer's DH
attribute as it does on the offerer's. The answerer MUST use the
same DH suite as the selected offer and MUST provide its public key
in the dhkey parameter. When it selects an offer and answers with
its public key, the answerer SHALL compute the Diffie-Hellman secret.
This secret SHALL be used for nonce processing as defined below.
2.8. Adding New DH Suites
Of the more than one dozen key-management schemes found in the draft
document, "Recommendations for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography" [NIST-800-56], this memo
selects several for SDP. The selection was made on the bases of
general usefulness to SDP applications and consideration of known
patent encumbrances. Nonetheless, it is likely that new DH suites
might be needed and these can be added in the future through a
published RFC. The RFC SHOULD reference NIST 800-56 and assign a DH
suite name to identify its scheme including whether it is static or
ephemeral, Finite Field or Elliptic Curve Cryptography, and give the
domain parameter set.
All DH suites in this document use single key-pair key agreement.
Future DH suites MAY add two-pair agreement schemes as found in Table
5 of the Draft Recommendation[NIST-800-56].
Baugher & McGrew Expires August 28, 2006 [Page 15]
Internet-Draft SDP-DH February 2006
3. The "nonce" DH Parameter
The "nonce" parameter carries input values that an endpoint uses to
derive a shared secret with the other endpoint. In order to use a
secret key derived from the DH exchange to protect a particular media
line, that media line SHALL contain a "nonce" parameter, which is
defined in this section. RFC {sdesc} defines the "inline" parameter
to convey a cryptographic key for a media stream. The nonce
parameter is used in place of the inline parameter. The two
parameters MUST NOT appear in the same media line. The inline
parameter carries secret information when it encodes an SRTP master
key and salt along with the optional lifetime and master key
indicator (MKI) values. The nonce carried by the nonce parameter is
passed to the DH Key Derivation Function (Section 3.2), along with
the DH public key from the dhkey parameter. The format of the dhkey
parameter is shown below.
nonce: salt || nonce ["|" lifetime] ["|" MKI]
The nonce parameter is structurally identical to inline in its
concatenated values, though it is semantically different. (Thus, the
routines that generate an inline parameter for an offer or an answer
can serve with little modification to produce a nonce offer or
answer.) Like the inline parameter, the nonce parameter includes two
random values for an SRTP key, a 14-byte "salt" and a nonce that is
16 bytes or longer depending on the SRTP crypto suite. However, the
nonce from the nonce parameter is not used directly, but instead is
passed to the key derivation function; the output of that function
provides the key that is associated with the salt. The inline
parameter also encodes the optional lifetime and MKI; the definition
and use of these fields is as defined by RFC {sdesc}. The ABNF for
nonce is given next and followed by the key derivation procedure and
offer/answer processing. Note that the nonce parameter MAY be
public; there is no requirement to keep it confidential.
3.1. Changes to RFC {sdesc} "crypto" Grammar
The following change is made to the RFC {sdesc} crypto attribute to
add the new parameter, "nonce". In the extended crypto attribute
grammar shown below, nonce is an alternative (a new key-method-ext)
to the inline parameter [sdesc].
Baugher & McGrew Expires August 28, 2006 [Page 16]
Internet-Draft SDP-DH February 2006
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param)
tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param)
key-param = key-method ":" key-info
key-method = "inline" / "nonce" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = %x21-3A / %x3C-7E ; visible (printing) characters
; except semi-colon
Figure 3.1-1: Extension to RFC {sdesc} key-method
Figure 3.1-1 is the general syntax for an RFC {sdesc} a=crypto line
that is extended with a new key method called "nonce." According to
RFC {sdesc}, crypto is specialized according to SDP transport; only
the RTP/SAVP (i.e. SRTP) transport has a crypto attribute defined in
RFC {sdesc}. This definition is shown below with its nonce
extension.
key-method = srtp-key-method
key-info = srtp-key-info
srtp-key-method = "inline" / "nonce" ; nonce key is nonce
srtp-key-info = key-salt ["|" lifetime] ["|" mki]
key-salt = 1*(base64) ; binary key and salt values
; concatenated together, and then
; base64 encoded [section 6.8 of
; RFC2046]
lifetime = ["2^"] 1*(DIGIT)
mki = mki-value ":" mki-length
mki-value = 1*DIGIT
mki-length = 1*3DIGIT ; range 1..128.
Figure 3.1-2: Extension to RFC {sdesc} srtp-key-method
Figure 3.1-2 is the RTP/SAVP (SRTP) syntax for a "nonce" method. The
"key-salt" in nonce is interpreted to be a 16-byte nonce and SRTP
salt value. The salt definition is not changed and is a 14-byte
binary value. Both nonce and key are base-64 encoded. The nonce is
used in a new type of SRTP master key generation as defined below.
Baugher & McGrew Expires August 28, 2006 [Page 17]
Internet-Draft SDP-DH February 2006
3.2. Generating SRTP Master Keys from Public Information
The key that results from the SDP DH key derivation function is used
as the SRTP master key. The master salt, key lifetime and key
indicator for an SRTP master key are taken from the salt field of the
"nonce" parameter. These are shown in Figure 3.1-2. DH key
derivation is invoked once for every SRTP master key that needs to be
generated, which is once for every media-level SRTP crypto attribute.
Thus, an SRTP master key is a special case of DH media-session key
derivation, which is described below.
3.3. Media-session Key Derivation
The DH suites of this document use the "Concatenation Key Derivation
Function" of Section 5.8.1 of the Draft Recommendation [NIST-800-56].
This key derivation function SHALL be used to derive SRTP master keys
prior to SRTP key derivation, which is unchanged by this memo. The
function is shown below with substitution of relevant parameters.
SHA-256(counter, Z, OtherInput),
where the values of Z and OtherInput are defined as follows.
counter: a 32-bit long string containing the value
00000001 (hexadecimal)
Z: Shared secret computed from the two DH pubkey values
OtherInput: contextID || keydatalen || pubkeymat
contextID: set to "offer"||"answer" where || is concatenation
keydatalen: length of SRTP master key, defined by SRTP Crypto
Suite
pubkeymat: the entire pubkeymat parameter, as an octet string
For larger key sizes, please refer to [NIST-800-56].
The Draft Recommendation defines a contextID and "shared data" that
depend on the particular protocol implementation. As defined here,
the SDP implementation uses the nonce as shared data. The nonce is
carried in the media-level nonce parameter as defined above.
According to the Draft Recommendation, the contextID is the
concatenation of endpoint identifiers that are also protocol
specific. As defined here, the SDP implementation uses "offer" and
"answer" for endpoint identifiers, which are fixed length and
concatenated. The shared secret Z is the DH secret that is computed
according to the Draft Recommendation. The final protocol-dependent
parameter is the key derivation function (kdf), which SHALL be SHA-
256. The processing of these values is given in the Draft
Recommendation but copied below for the convenience of the reader.
Baugher & McGrew Expires August 28, 2006 [Page 18]
Internet-Draft SDP-DH February 2006
"Process:
1. reps = upperbound(keydatalen / hashlen).
2. If reps > (232 ?1), then ABORT: output "Invalid" and stop.
3. Initialize a 32-bit, big-endian bit string counter as 0000000116.
4. For i = 1 to reps by 1, do the following:
4.1 Compute Hashi = H( counter || Z || contextID || nonce ).
4.2 Increment counter (modulo 232), treating it as an unsigned
32-bit integer.
5. Let Hhash be set to Hashreps if (keydatalen / hashlen) is an
integer; otherwise, let Hhash be set to the
(keydatalen mod hashlen) leftmost bits of Hashreps.
6. Set DerivedKeyingMaterial =
Hash1 || Hash2 || ... || Hashreps-1 || Hhash.
Output:
The bit string DerivedKeyingMaterial of length keydatalen bits (or
"Invalid"). Any scheme attempting to call this key derivation
function with keydatalen greater than or equal to hashlen*(2^32 - 1)
shall output "Invalid" and stop without outputting
DerivedKeyingMaterial.
Note:
The hashlen is the length in bits of the output block of the hash
function, which is a 256-bit SHA-256 message digest."
3.4. Offer/Answer Processing
Use of the nonce parameter follows the Offer/Answer processing rules
of RFC {sdesc} with one additional dependency: The answerer MUST
reject any media-level crypto attribute with a nonce parameter if
there is no session-level Diffie-Hellman secret. If there were no DH
attribute in the SDP message and no accepted DH attribute in the
answer, then there can be no Diffie-Hellman secret. Thus, successful
processing of nonce is dependent upon the successful processing of
the SDP DH attribute.
The answerer MUST use a nonce parameter in the answer for each RTP/
SAVP media stream that it will source.
Baugher & McGrew Expires August 28, 2006 [Page 19]
Internet-Draft SDP-DH February 2006
4. Person-to-Person Authentication
Diffie-Hellman exchanges MUST be externally authenticated to prevent
active attacks in the middle. For phone calls between persons, a
strong form of external authentication is for each user to validate a
number that is derived from the shared secret. Both users therefore
need a common means to arrive at the same output. The default method
of this document is to use the DH shared secret as an HMAC key and
the contextID concatenated with values of the DH Suite chosen in the
answer.
FINGERPRINT = HMAC-SHA1 ( Z, "offeranswer" || DH_Suite
|| Offer_dhkey
|| Answer_dhkey )
DH_Suite = ( "Stat_FFDH_Group_2" /
"Ephem_ECDH_Group_19" /
"Stat_ECDH_Grou_19" /
"Stat_FFDH_Group_14" /
"Ephem_FFDH_Group_14" )
Notes:
1. Z is the shared Diffie-Hellman secret
2. FINGERPRINT truncation and phonetic alphabet are implementation-
dependent.
Baugher & McGrew Expires August 28, 2006 [Page 20]
Internet-Draft SDP-DH February 2006
5. Security Considerations
This document improves the security of signaling protocols that use
Session Description Protocol (SDP) for SRTP cryptographic context
establishment - and potentially other SDP media "transports" as well.
As described in the introduction, the public key exchanges establish
a shared secret between endpoints using public values in the SDP
message even in the absence of integrity protection. There are
vulnerabilities to this method, however, that REQUIRE use of external
authentication and special consideration for bid-down attacks when
the SDP message contains multiple DH and crypto offers and is not
integrity-protected. Each are considered below.
5.1. Man-in-the-Middle Attacks
A Diffie-Hellman exchange that is not externally authenticated is
vulnerable to a man-in-the-middle attack. In the context of an SDP
offer/answer exchange, the threat is that an attacker in control of
the signaling channel will substitute its DH public key for that of
the offerer and forward it to the answerer. Upon receipt of the
answer, the attacker will substitute its DH public key for that of
the answerer and forward it on to the offerer. This attack succeeds
in obtaining media data sent between the two endpoints when the
attacker is also in the middle of the media channel: With its two DH
secrets, the attacker has a shared secret with the answerer, another
shared secret with the offerer, and can decrypt each packet from one
and re-encrypt it for the other. Neither the offerer or answerer can
necessarily detect this attack.
There are three defenses to the "man-in-the-middle" attack. One
defense is a "person-to-person authentication procedure" where one
user reads a hash of the DH secret to the other user who verifies
that they have the same truncated value (as done in the AT&T Model
3600 Telephone Security Device [Schneier]). This procedure reveals a
man-in-the-middle attack because each truncated hash will be
different when two DH secrets are managed by the man-in-the-middle.
By assumption, a man-in-the-middle cannot force the hashes of its
distinct keys with each endpoint to match, nor can the attacker
impersonate the voice of either side well enough to substitute the
correct values over the phone. Manual and somewhat laborious,
person-to-person authentication needs to be done only once to admit a
static key onto the key ring so the procedure need not be repeated
for each phone call. This procedure is secure and does not require
pre-existing infrastructure between the calling and called parties.
This procedure will only work, however, when there are people in
communication over the telephone. For machine-to-machine or human-
to-machine sessions, there needs to be a pre-existing relationship
either from a previous run of person-to-person authentication or with
Baugher & McGrew Expires August 28, 2006 [Page 21]
Internet-Draft SDP-DH February 2006
a common, trusted third party.
The second defense against a man-in-the-middle attack uses a pre-
existing relationship between each person and their service provider,
who attests to the fact that the caller is authorized to use the
"from" address in the SIP signaling message that encapsulates the
SDP. This is the "SIP Identity" solution, which establishes that the
SIP "from" address is not forged. The service provider will use its
private key to integrity-protect the SIP message and to speak on
behalf of the domain from which the message originates. In this
case, the user MUST trust the service provider to not alter the DH
public key that the user has placed in the message. The user
therefore trusts the service provider to not launch a man-in-the-
middle attack just as the customer of a third-party certificate
authority trusts that authority.
If there exists a third party certificate authority that each
endpoint trusts to correctly identify the other endpoint, then this
method can serve to authenticate each endpoint to the other and
prevent a man-in-the-middle attack, but recent experience has shown
that no such authority exists for any-to-any authorization
applications such as telephony. If such a third party did exist,
then the endpoint implicitly trusts the third party to not launch a
man-in-the-middle's attack.
Whenever a third party or service provider is trusted to correctly
identify the source domain of an endpoint, this external
authentication technique can also use person-to-person authentication
as a failsafe procedure especially in cases where there is no
integrity protection of the SDP message.
5.2. Bid-down Attack
There is a case where integrity protection of the SDP message could
thwart an attack: When multiple offers are contained in the SDP
message, an attacker in control of the signaling channel might alter
the message to always use the weakest DH-suite offer. The use of
multiple offers serves to match security policies between the
endpoints and is a convenience for periods when a transition from one
DH suite to another. An example is the current transition from SHA-1
to SHA-256 hashing for certain security applications. It is a matter
of security policy, however, that such a "bid-down attack" not bid
down the security below a minimum threshold. In any case, it is
RECOMMENDED that answers that are lower than the first (preferred)
offer be logged and available to any human user.
Baugher & McGrew Expires August 28, 2006 [Page 22]
Internet-Draft SDP-DH February 2006
5.3. Ephemeral and Static Keys
Certain applications require perfect forward secrecy (PFS), which is
a property of session keys that are generated using an ephemeral
Diffie-Hellman secret. When the DH public keys and the derived DH
secret are ephemeral, they are destroyed (zeroed) immediately after
use along with all intermediate results. Thus, the secret used to
generate the session keys is destroyed even before any session key is
used. For ephemeral DH suites, an attacker gains no advantage by
recording all the media streams in hope of stealing the private key
of one of the communicating parties. The ephemeral secret and all
intermediate computational results MUST be destroyed immediately
after they are used [NIST-800-56].
Static DH suites lack the PFS property since they exist after the
session terminates. Although a static key that is used for only a
single multimedia session might be considered ephemeral, the fact
that the keys MUST be destroyed immediately after use is not signaled
between the two parties. Although one endpoint might treat its
static key as an ephemeral key, there is no guarantee that the other
party will do the same.
When the parties desire PFS for a multimedia session, they MUST use
an ephemeral DH key. All ephemeral keying materials MUST NOT be
cached, written to a file, or maintained following their use in
generating session keys. Once used, any and all storage locations of
keys and intermediate results MUST be set to zeros. This is the
opposite of the recommended procedure for static keys: An
implementation SHOULD cache static keys when system resources are
available and for a period of time determined by policy.
Baugher & McGrew Expires August 28, 2006 [Page 23]
Internet-Draft SDP-DH February 2006
6. IANA Considerations
IANA is requested to register a new SDP session-level attribute
("att-field" ) named "DH". "Static_FFDH_Group_2,
"Static_ECDH_Group_19", "Ephem_ECDH_Group_19", Statid_FFDH_Group_14",
"Ephem_FFDH_Group_14", and "dhkey" are DH parameter names.
IANA is further requested to register a new SDP media level att-field
for crypto named "nonce".
Baugher & McGrew Expires August 28, 2006 [Page 24]
Internet-Draft SDP-DH February 2006
7. Acknowledgements
The authors thank Cullen Jennings and Flemming Andreasen for their
ideas, suggestions, and review.
Baugher & McGrew Expires August 28, 2006 [Page 25]
Internet-Draft SDP-DH February 2006
8. References
8.1. Normative References
[FIPS-180-2]
"Secure Hash Standard (http://csrc.nist.gov/publications/
fips/fips180-2/fips180-2withchangenotice.pdf)",
August 2002.
[FS] Fu, D. and J. Solinas, "ECP Groups for IKE, Work in
Progress", 2004.
[NIST-800-56]
Barker, E., Johnson, D., and M. Smid, "Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography, NIST Special Publication 800-56",
July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[SIPidentity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", 2005.
Baugher & McGrew Expires August 28, 2006 [Page 26]
Internet-Draft SDP-DH February 2006
[sdesc] Andreasen, F., Baugher, M., and D. Wing, "SDP Security
Descriptions for Media Streams, IETF Work in Progress,
2006", 2006.
8.2. Informative References
[DVW] Diffie, W., van Oorschot, P., and M. Wiener,
""Authentication and authenticated key exchanges,"
Designs, Codes, and Cryptography, vol. 2, no. 2, pp. 107--
125, 199", 1992, <Diffie, van Oorschot, Wiener>.
[IEEE1363]
"IEEE P1363, Standard Specifications for Public Key
Cryptography, Institute of Electrical and Electronics
Engineers", 2004.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RS] Raymond, J-F. and A. Stiglic, "Security Issues in the
Diffie-Hellman Key Agreement Protocol
(http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf)",
2005.
[SEC1] "SEC1: Elliptic Curve Cryptography, Standards for
Efficient Cryptogrphy, Certicom Corp., 1999", April 2003.
[Schneier]
Schneier, B., "Applied Cryptography", 1996.
[WE] Ellison, C. and J. Walker, "UPnP(TM) Security Ceremonies",
October 2003.
[Zimmermann]
"Zimmermann, Philip, The Official PGP User's Guide, The
MIT Press, 1995 ISBN 0-262-74017-6 (Out of Print)", 2005.
Baugher & McGrew Expires August 28, 2006 [Page 27]
Internet-Draft SDP-DH February 2006
Authors' Addresses
Mark Baugher
Cisco Systems, Inc.
800 East Tasman Drive
San Jose, CA 95164
US
Phone: (503) 245-4543
Email: mbaugher@cisco.com
David A. McGrew
Cisco Systems, Inc.
800 East Tasman Drive
San Jose, CA 95164
US
Phone: (301) 349-5815
Email: mcgrew@cisco.com
Baugher & McGrew Expires August 28, 2006 [Page 28]
Internet-Draft SDP-DH February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baugher & McGrew Expires August 28, 2006 [Page 29]