[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/