[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
HIPRG                                                      H. Tschofenig
Internet-Draft                                              M. Shanmugam
Intended status: Informational             Siemens Networks GmbH & Co KG
Expires: April 26, 2007                                         F. Muenz
                                                        October 23, 2006


                  Using SRTP transport format with HIP
                 draft-tschofenig-hiprg-hip-srtp-02.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 April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Tschofenig, et al.       Expires April 26, 2007                 [Page 1]


Internet-Draft    Using SRTP transport format with HIP      October 2006


Abstract

   The Host Identity Protocol (HIP) is a signaling protocol which adds a
   new layer between the traditional Transport and the Network layer.
   HIP is an end-to-end authentication and key exchange protocol, which
   supports security and mobility in a commendable manner.  The HIP base
   specification is generalized and purported to support different key
   exchange mechanisms in order to provide confidentiality protection
   for the subsequent user data traffic.  This draft explains a
   mechanism to establish Secure Real Time Protocol associations, to
   protect the user data packets, by using HIP.








































Tschofenig, et al.       Expires April 26, 2007                 [Page 2]


Internet-Draft    Using SRTP transport format with HIP      October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  SRTP Parameter Exchange in HIP . . . . . . . . . . . . . . . .  7
     4.1.  Setting up an SRTP Association . . . . . . . . . . . . . .  7
     4.2.  Rekeying . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Parameter and Packet Formats . . . . . . . . . . . . . . . . .  9
     5.1.  General Parameters (SRTP_PARAM)  . . . . . . . . . . . . .  9
     5.2.  Timestamp (SRTP_T) . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Pseudo-random byte-string (SRTP_RAND)  . . . . . . . . . . 11
     5.4.  Security Policies (SRTP_SP)  . . . . . . . . . . . . . . . 12
     5.5.  Master Key Identifier (SRTP_MKI) . . . . . . . . . . . . . 14
     5.6.  NOTIFY Parameter . . . . . . . . . . . . . . . . . . . . . 14
   6.  Packet Processing  . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Processing Outgoing Application Data . . . . . . . . . . . 15
     6.2.  Processing Incoming Application Data . . . . . . . . . . . 15
     6.3.  HMAC and SIGNATURE Calculation and Verification  . . . . . 15
     6.4.  Processing Incoming SRTP Initialization (R1) . . . . . . . 15
     6.5.  Processing Incoming SRTP Reply (I2)  . . . . . . . . . . . 16
     6.6.  Dropping HIP Associations  . . . . . . . . . . . . . . . . 16
     6.7.  Initiating SRTP master key rekeying  . . . . . . . . . . . 16
     6.8.  Finalizing Rekeying  . . . . . . . . . . . . . . . . . . . 17
     6.9.  Processing NOTIFY Packets  . . . . . . . . . . . . . . . . 18
   7.  Implementation Considerations  . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     8.1.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 20
     8.2.  Man in the Middle Attack . . . . . . . . . . . . . . . . . 20
     8.3.  Eavesdropping  . . . . . . . . . . . . . . . . . . . . . . 20
     8.4.  Authentication . . . . . . . . . . . . . . . . . . . . . . 21
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26













Tschofenig, et al.       Expires April 26, 2007                 [Page 3]


Internet-Draft    Using SRTP transport format with HIP      October 2006


1.  Introduction

   The Host Identity Protocol (HIP) [I-D.ietf-hip-base] provides a way
   to separate the dual role of IP (end point identifier and locator) by
   adding a new layer between the traditional Network and Transport
   layer.  This separation helps the end host to achieve mobility,
   furthermore, HIP provides better security features (like end-to-end
   authentication, confidentiality for the data traffic etc) than other
   multi6 proposals.

   HIP is based on public key cryptography.  All HIP hosts have a
   public/private key pair.  HIP introduces a new name space called Host
   Identity.  It is nothing but the public key of an asymmetric key
   pair.  It provides a rapid exchange of host identities (public keys)
   between communicating hosts, after mutual authentication, a HIP
   association is established.  For operational purposes, HIP uses Host
   Identity Tags (HITs) [I-D.ietf-hip-base], which is hash of the public
   key.  During the base exchange, the hosts generate a shared keying
   material using an authenticated Diffie-Hellman exchange.  Note that
   the HIP base exchange provides mutual authentication of the hosts,
   but does not specify any mechanism for protecting data packets.
   [I-D.ietf-hip-esp] draft proposes a way to use IPsec ESP format with
   HIP.

   Secure Real Time Protocol (SRTP) is a profile for Real Time Protocol
   (RTP), which provides a framework for providing encryption,
   integrity, message authentication, confidentiality and protection
   against replay attacks for the real-time data traffic.  SRTP mandates
   the use of an external key management protocol to exchange keys and
   cryptographic parameters, which are used to derive keys (like cipher
   suites, random number etc.,).  This draft proposes a way to exchange
   SRTP relevant parameters during the HIP base exchange.  Appendix A
   describes one possible use case to support this document.

   This document is organized as follows.  Section 4 describes the
   revised base exchange, Section 5 presents the packet format, Section
   6 explains the packet processing and Section 7 talks about the key
   management.

   This document was developed in the context of investigating the
   benefits of using HIP for SIP.










Tschofenig, et al.       Expires April 26, 2007                 [Page 4]


Internet-Draft    Using SRTP transport format with HIP      October 2006


2.  Terminology

   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 [RFC2119] .

   This draft uses the terminology defined in [I-D.ietf-hip-base] and
   [RFC3261] .

   The term MKI, an optional parameter, refers to Master Key Identifier
   used in SRTP packets.








































Tschofenig, et al.       Expires April 26, 2007                 [Page 5]


Internet-Draft    Using SRTP transport format with HIP      October 2006


3.  Goals

   To facilitate the use of SRTP, the HIP base exchange messages require
   some minor additions to the parameters transported.  In the R1
   packet, the responder adds the necessary parameters, which contains
   transforms and other related information for the SRTP association,
   before sending it to the Initiator.  The Initiator gets the proposed
   transforms, selects one of those proposed transforms, and adds it to
   the I2 packet, as well as other information in the corresponding
   parameters.

   In this context, the goal of our proposal is to,

   o  define new parameter exchange for exporting the relevant SRTP
      parameters in the HIP base exchange.

   o  describe the relevant packet formats.


































Tschofenig, et al.       Expires April 26, 2007                 [Page 6]


Internet-Draft    Using SRTP transport format with HIP      October 2006


4.  SRTP Parameter Exchange in HIP

   In this section, the protocol for setting up an SRTP association to
   be used with HIP association is described.

4.1.  Setting up an SRTP Association

   Setting up an SRTP Association between hosts using HIP consists of
   two messages passed between the hosts.  The parameters are included
   in R1 and I2 messages during base exchange.

   Initiator                              Responder
                    I1
    ------------------------------------------->
            R1: SRTP_T, SRTP_PARAM, KEY_PARAM
   <--------------------------------------------
            I2: SRTP_T, SRTP_PARAM, KEY_PARAM
   ------------------------------------------->
                    R2
   <--------------------------------------------

                 Figure 1: Setting up an SRTP Association

   The integration of HIP and SRTP requires some changes, as mentioned
   earlier, in the HIP parameters.  The changes are (will be) adding,

   SRTP_T: The timestamp, used mainly to prevent replay attacks.

   The SRTP_PARAM contains the information about the general description
   of the message exchange.  It is used for mapping a Crypto Sessions
   (CS) to security protocol sessions.

   KEYING parameter (KEY_PARAM) contains

      SRTP_RAND: Random/pseudo-random byte-string, RAND(nonce) is used
      as a fresh value for the key generation.

      SRTP_SP: The security policies for the data security protocol.
      (eg. algorithms and transforms and PRFs supported by the peers).
      The cipher suites can be negotiated from R1/I2 packet.

      SRTP_MKI : to identify the Master key and Master salt.

   The R1 message contains the KEYING PARAMS, in which the sending host
   defines the possible Algorithms and transforms, random number and,
   optionally, a MKI it is willing to use for the SRTP association.

   The I2 message contains the response to KEYING PARAMS received in the



Tschofenig, et al.       Expires April 26, 2007                 [Page 7]


Internet-Draft    Using SRTP transport format with HIP      October 2006


   R1 message.  The sender must select one of the proposed transforms
   from the SP parameter in the R1 message and include the selected one
   in the SP parameter in the I2 packet.  In addition to the transform,
   the host includes the RAND parameter, containing the random value
   (and optionally MKI) to be used as a salt by the peer host.  In the
   R2 message, HIP exchange is finalized.

4.2.  Rekeying

   Rekeying can be supported using the UPDATE packet of HIP.  The peer
   which wants to rekey should use the UPDATE packet with the
   appropriate parameters.  The mechanism is explained below:


   Initiator                                                  Responder

     UPDATE: SRTP_T, SRTP_PARAM, KEYING PARAMS [,DIFFIE_HELLMAN]
   ------------------------------------------------------------->
     UPDATE: SRTP_T, SRTP_PARAM, KEYING PARAMS [,DIFFIE_HELLMAN]
   <-------------------------------------------------------------
                         UPDATE ACK
   ------------------------------------------------------------->

                       Figure 2: Rekeying mechanism

   Figure 2 depicts the rekeying scenario.  Here, assume that the
   Initiator wants to rekey after the Initial exchange.  It can send the
   rekeying parameters in the Update packet, includes its new Diffie-
   Hellmann value, and sends it to the Responder.  It may send a new MKI
   value to identify the incoming packet.

   The other parameters are explained in [I-D.ietf-hip-base].  The
   Responder checks the return routability by sending the Update seq
   message containing its Diffie-Hellmann value and relevant parameters
   for the rekeying.  After receiving the packet, the Initiator sends
   the ACK thereby both the peers conclude the rekeying procedure and
   now on, the peers expect to receive the traffic in the new keying
   material.













Tschofenig, et al.       Expires April 26, 2007                 [Page 8]


Internet-Draft    Using SRTP transport format with HIP      October 2006


5.  Parameter and Packet Formats

   This section discusses the SRTP related new parameters and presents
   the proposed packet format.

   The following list gives an overview of the parameters to be
   exchanged in addition to the HIP base exchange:

      Master Key and its length - obtained from Diffie-Hellmann key
      exchange

      Master Salt - RAND in the KEYING parameter

      MKI - Master Key Identifier

      Security Policies (SP) - Each policy will define pseudo-random
      functions, algorithms and transforms for the establishment of a
      Cryptographic Context for SRTP.

      Timestamp - Used for preventing replay attacks.

      Session keys are derived using Master key, Master salt and SP and
      the details are up to the key management protocol.

   The new parameters contain five elements summarized in the following
   table:

         Parameter        Type   Length     Data

         SRTP_PARAM       40000  variable   Mapping Crypto Sessions
                                                to security protocol
                                            sessions
         SRTP_T           40001  4          Used mainly to prevent
                                            replay attacks
         SRTP_RAND        40002  14         used as a fresh value for
                                            the key generation
         SRTP_SP          40003  variable   algorithms, transforms, PRFs
                                            supported by the peers
         SRTP_MKI         40004  variable   Master Key Identifier

   The parameters SRTP_RAND, SRTP_SP and SRTP_MKI together form the
   KEYING (KEY_PARAM) parameters.

5.1.  General Parameters (SRTP_PARAM)

   The general parameter is used for mapping a Crypto Sessions (CS) to
   security protocol sessions.




Tschofenig, et al.       Expires April 26, 2007                 [Page 9]


Internet-Draft    Using SRTP transport format with HIP      October 2006


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                         CSB ID                                !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! #CS           ! CS ID map info                | RESERVED      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Policy_no_1   ! SSRC_1                                        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! SSRC_1 (cont) ! ROC_1                                         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! ROC_1 (cont)  ! Policy_no_2   ! SSRC_2                        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! SSRC_2 (cont)                 ! ROC_2                         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! ROC_2 (cont)                  !                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Policy_no_#CS !           SSRC_#CS                            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !SSRC_#CS (cont)!           ROC_#CS                             !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! ROC_#CS (cont)!
      +-+-+-+-+-+-+-+-+


      Fig 4: Mapping parameters

      Type:   40000 (experimental identifier range)
      Length: variable
      Value:  Mapping information

      CSB ID (32 bits): identifies the CSB.  It is RECOMMENDED that the
      CSB ID be chosen at random by the Responder and sent with the R1
      packet.  This ID MUST be unique between each Initiator-Responder
      pair, i.e., not globally unique.  A Responder MUST check for
      collisions when choosing the ID (if the Responder already has one
      or more established CSBs with the Initiator).  The Initiator uses
      the same CSB ID in the response.

      #CS (8 bits): indicates the number of Crypto Sessions that can be
      handled concurrently by a CSB.  A CSB may handle up to 255 CS at a
      time.  However, it is unlikely that this limited will be reached.
      The integer 0 is interpreted as no CS included.  This may be the
      case in an initial setup message.



Tschofenig, et al.       Expires April 26, 2007                [Page 10]


Internet-Draft    Using SRTP transport format with HIP      October 2006


      CS ID map info (16 bits): identifies the crypto session(s) for
      which the SA should be created.

      Policy_no_i (8 bits): The security policy applied for the stream
      with SSRC_i.  The same security policy may apply for all CSs.

      SSRC_i (32 bits): specifies the SSRC that MUST be used for the
      i-th SRTP stream.

      ROC_i (32 bits): Current rollover counter used in SRTP.

   NOTE: The stream using SSRC_i will also have Crypto Session ID equal
   to no i (NOT to the SSRC).

5.2.  Timestamp (SRTP_T)

   The timestamp, used mainly to prevent replay attacks.  As in the SRTP
   packet format, a 32-bit value is used to store the timestamp.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp (T)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Fig 4: Timestamp parameter

      Type:   40001 (experimental identifier range)
      Length: 4
      Value:  Timestamp

5.3.  Pseudo-random byte-string (SRTP_RAND)

   The RAND or master salt parameter is used as a fresh value for the
   key generation.  The RAND parameter is a 112 bit quantity.














Tschofenig, et al.       Expires April 26, 2007                [Page 11]


Internet-Draft    Using SRTP transport format with HIP      October 2006


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                 Pseudo-random byte-string (RAND)              |
      |                                                               |
      |                                                               |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               | reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Fig 5: Pseudo-random byte-string parameter

      Type:   40002 (experimental identifier range)
      Length: 14
      Value:  Pseudo-random byte-string

5.4.  Security Policies (SRTP_SP)

   The security policies for the data security protocol (e.g.,
   algorithms, transforms and PRFs supported by the peers).  The cipher
   suites can be negotiated from I2/R2 packet.  The security policy
   parameters are grouped together for being used with the policy
   selector in the mapping parameter, that is a SRTP_SP parameter may
   actually consist of multiple policies.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type                          | Length                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~ Security policy parameters                                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Fig 6: Security policy parameters

      Type:   40003 (experimental identifier range)
      Length: variable
      Value:  See below

   The security policy parameters themselves are built up by a set of
   Type/Length/Value fields:





Tschofenig, et al.       Expires April 26, 2007                [Page 12]


Internet-Draft    Using SRTP transport format with HIP      October 2006


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type          | Length        | Policy No.    | Value         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type (8 bits): specifies the type of the parameter.

   Length (8 bits): specifies the length of the Value field (in bytes).

   Policy No. (8 bits): specifies the policy to which this TLV belongs.
   It is used in conjunction with the Mapping parameter.  All values
   (0-255) may be used for policy identification.

   Value (variable length): specifies the value of the parameter.

      Type | Length | Meaning                    | Value
      -----+--------+----------------------------+--------------------
      1    | 1      | SRTP and SRTCP encr transf | see below
      2    | 2      | Encr session key length    | 128
      3    | 1      | SRTP and SRTCP auth transf | see below
      4    | 2      | Auth session key length    | 160
      5    | 2      | Tag length                 | 80
      6    | 4      | SRTP prefix_length         | var(default 0)
      7    | 1      | Key derivation PRF         | see below
      8    | 8      | Key derivation rate        | var(default 0)
      9    | 8      | SRTP-packets-max-lifetime  | var
      10   | 8      | SRTCP-packets-max-lifetime | var
      11   | 1      | Forward Error Control      | 2-bits

   For the Encryption transforms, a one byte length is enough.  The
   currently defined possible Values are:

        SRTP and SRTCP encr transf | Value
        ---------------------------+------
        NULL                       | 0
        AES-CM                     | 1
        AES-F8                     | 2

   where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [RFC3711].

   For the Authentication transforms, a one byte length is enough.  The
   currently defined possible Values are:

        SRTP and SRTCP auth transf  | Value
        ----------------------------+------
        NULL                        | 0
        HMAC-SHA-1                  | 1



Tschofenig, et al.       Expires April 26, 2007                [Page 13]


Internet-Draft    Using SRTP transport format with HIP      October 2006


   For the Key derivation PRF, a one byte length is enough.  The
   currently defined possible values are:

        Key derivation PRF      | Value
        ------------------------+-------
        NULL                    | 0
        AES_CM                  | 1

5.5.  Master Key Identifier (SRTP_MKI)

   The MKI identifies the master key and master salt from which the
   session key(s) were derived that authenticate and/or encrypt the
   particular packet.  This parameter is OPTIONAL.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                         MKI (variable)                        ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Fig 7: SRTP MKI parameter

      Type:   40004 (experimental identifier range)
      Length: variable
      Value:  Master Key Identifier (MKI)

5.6.  NOTIFY Parameter

   The HIP base specification defines a set of NOTIFY error types.  The
   following error types are required for describing errors in SRTP
   security policy during negotiation.

            NOTIFY PARAMETER - ERROR TYPES           Value
            ------------------------------           -----

            NO_SRTP_PROPOSAL_CHOSEN                   TBD

               None of the proposed SRTP Transform in the proposed
               security policy was acceptable.

            INVALID_SRTP_TRANSFORM_CHOSEN             TBD

               The SRTP chosen parameters  from the proposed security
               policy proposals do not correspond to those offered
               by the responder.




Tschofenig, et al.       Expires April 26, 2007                [Page 14]


Internet-Draft    Using SRTP transport format with HIP      October 2006


6.  Packet Processing

   In general, packet processing is specified in the HIP base
   specification [I-D.ietf-hip-base].  This section provides an overview
   of changes needed when using the new SRTP extensions.

6.1.  Processing Outgoing Application Data

   When the SRTP format is used, the outgoing application data will be
   encrypted using a cryptographic context.  Details about the handling
   of outgoing SRTP traffic is described in [RFC3711] Section 3.3.

6.2.  Processing Incoming Application Data

   When the SRTP format is used, the incoming application data will be
   decrypted using a cryptographic context.  Details about the handling
   of incoming SRTP traffic is described in [RFC3711] Section 3.3.

6.3.  HMAC and SIGNATURE Calculation and Verification

   The new HIP parameters described in this document, SRTP_PARAM,
   SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI must be protected using HMAC
   and signature calculations.  In a typical implementation, they are
   included in R1, I2, and UPDATE packet HMAC and SIGNATURE calculations
   as described in [I-D.ietf-hip-base].

6.4.  Processing Incoming SRTP Initialization (R1)

   The SRTP key exchange is initialized in the R1 message.  The
   receiving host (Initiator) selects the SRTP transforms from the
   presented values in the R1 packet and establishes its SRTP
   Cryptographic Context.  For this the SRTP_SP will provide the
   transforms and pseudo-random functions, the SRTP_MAPPING parameters
   will provide information about what policy applies for which Crypto
   Session (CS).  If no suitable value is found, the negotiation is
   terminated.

   The selected values are subsequently used when generating and using
   session keys according to the negotiated SP, and when sending the
   reply packet I2.  If the proposed alternatives are not acceptable to
   the system, it may abandon the SRTP establishment negotiation, or it
   may resend the I1 message within the retry bounds.

   After creating cryptographic context, and performing other R1
   processing, the system prepares and creates session keys derived from
   the exchanged master key complying to the negotiated SPs.  The
   Initiator will then send the I2 packet with the selected SRTP
   transforms.



Tschofenig, et al.       Expires April 26, 2007                [Page 15]


Internet-Draft    Using SRTP transport format with HIP      October 2006


6.5.  Processing Incoming SRTP Reply (I2)

   The following steps are required to process the incoming SRTP
   initialization reply in I2 for creating the correct Cryptographic
   Context on Responder side.  It is assumed that the I2 packet has been
   accepted for processing (e.g., has not been dropped due to HIT
   comparisons as described in [I-D.ietf-hip-base]):

      The SRTP_SP and SRTP_MAPPING parameters are verified and they MUST
      have the same number of proposed policies in R1 and each policy
      MUST match the values offered in the initialization packet.

      The SRTP_MKI field is parsed to obtain the MKI that will be used
      for selecting the appropriate master key.

      The system creates session keys derived from the master key,
      master salt and security policy for a certain SRTP stream.

      Upon successful processing of the initialization reply message, a
      possible old master key and session keys are dropped and the new
      ones are installed, and a finalizing packet, R2, is sent.
      Possible ongoing rekeying attempts are dropped.

6.6.  Dropping HIP Associations

   When the system drops a HIP association, as described in the HIP base
   specification, the SRTP layer and any results from exchanges are not
   affected.

6.7.  Initiating SRTP master key rekeying

   During SRTP rekeying, the hosts exchange new master keys from which
   session keys will be derived.  Use of the MKI for rekeying is
   RECOMMENDED

   A system may initiate the SRTP rekeying procedure at any time.  The
   system MUST NOT replace its current master key until the rekeying
   packet exchange successfully completes.

   The rekeying procedure uses the UPDATE mechanism defined in
   [I-D.ietf-hip-base].  Because each peer must update their master
   keys, the rekeying process requires that each side both send and
   receive an UPDATE.  A system will then rekey the session keys when it
   has sent parameters to the peer and has received both an ACK of the
   relevant UPDATE message and corresponding peer's parameters.  It may
   be that the ACK and the required HIP parameters arrive in different
   UPDATE messages.  This is always true if a system does not initiate
   SRTP update but responds to an update request from the peer, but may



Tschofenig, et al.       Expires April 26, 2007                [Page 16]


Internet-Draft    Using SRTP transport format with HIP      October 2006


   also occur if two systems initiate update nearly simultaneously.  In
   such a case, if the system has an outstanding update request, it
   saves the one parameter and waits for the other before completing
   rekeying.

   The following steps define the processing rules for initiating an
   SRTP update:

      The system decides whether to continue to use the existing master
      key or to create a new one.  In the latter case, the system MUST
      generate a new Diffie-Hellman public key.  When using SRTP default
      transforms, the master key MUST be replaced before any of the
      index spaces are exhausted for any of the streams protected by one
      and the same master key.

      The system creates an UPDATE packet, which contains the
      SRTP_PARAM, SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI parameter.  In
      addition, the host MUST include DIFFIE_HELLMAN parameter.

      The system sends the UPDATE packet.  For reliability, the
      underlying UPDATE retransmission mechanism SHOULD be used.

      The system MUST NOT delete its existing master key, but continue
      using them if its policy still allows.

      In case a protocol error occurs and the peer system acknowledges
      the UPDATE but does not itself send an SRTP parameters, the system
      may not finalize the outstanding session key update request.  To
      guard against this, a system MAY re-initiate the SRTP update
      procedure after some time waiting for the peer to respond, or it
      MAY decide to abort the SRTP update after waiting for an
      implementation-dependent time.  The system MUST NOT keep an
      oustanding SRTP update request for an indefinite time.

   To simplify the state machine, a host MUST NOT generate new UPDATEs
   while it has an outstanding SRTP update request, unless it is
   restarting the update process.

6.8.  Finalizing Rekeying

   A system finalizes rekeying when it has both received the
   corresponding UPDATE acknowledgement packet from the peer and it has
   successfully received the peer's UPDATE.  The following steps are
   taken:







Tschofenig, et al.       Expires April 26, 2007                [Page 17]


Internet-Draft    Using SRTP transport format with HIP      October 2006


      If the received UPDATE messages contains a new Diffie-Hellman key,
      the system has a new Diffie-Hellman key from initiating SRTP
      update, or both, the system selects the new master key.

      The system draws session keys from the new master key.

      The system cancels any timers protecting the UPDATE.

6.9.  Processing NOTIFY Packets

   The processing of NOTIFY packets is described in the HIP base
   specification.







































Tschofenig, et al.       Expires April 26, 2007                [Page 18]


Internet-Draft    Using SRTP transport format with HIP      October 2006


7.  Implementation Considerations

   This section explains the implementation considerations for the HIP-
   SRTP exchange.  After the initial base exchange, both peers have the
   same master key, salt and agreed crypto transforms (including pseudo
   random function).  When the application receives the data traffic
   after the base exchange, an API is invoked and asks the HIP daemon
   for the appropriate key to process the data packet.

   Figure 15 depicts the example implementation architecture of the
   proposed mechanism:



                                +------------+
   -------------+   API         | KEY ENGINE |
    Application |<------------->|            |
                |               |            |
                |               |            |
                |               | HIP daemon |
                |               +------------+
                |
    User space  |
   -------------+
             PF_INET ||          || PF_RAW
   ==================||==========||=============
                     ||          ||
    Kernel space
                     +--------------+
                     | TCP|UDP / IP |
                     +--------------+

              Figure 15: Example Implementation Architecture


















Tschofenig, et al.       Expires April 26, 2007                [Page 19]


Internet-Draft    Using SRTP transport format with HIP      October 2006


8.  Security Considerations

   Security is considered throughout this document.

   The initial keying material is generated using using Diffie-Hellman
   procedure.  This document extends the usage of UDPATE packet, defined
   in the base specification, for rekeying.  The hosts may rekey for the
   generation of new keying material using Diffie-Hellman procedure.
   This mechanism enjoys the security protection provided by base
   exchange using HMAC and signature verifications.

   In this approach, we have tried to extend the HIP base exchange to
   support SRTP based key management scheme.  We have listed the
   following security mechanisms that are incorporated with this idea:

8.1.  Denial of Service

   Threat:

   A denial of service attack typically overloads the attacked nodes by
   exploiting any state creation, CPU intensive calculation or simply
   overloading their maximum available bandwidth.

   Countermeasures:

   This approach enjoys the merits of HIP like resisting CPU and memory
   exhaustive DoS attacks by forcing the caller to calculate the
   solution for a cryptographic puzzle.  This provides only a basic DoS
   protection for the callee.

8.2.  Man in the Middle Attack

   Threat:

   An adversary might want to modify the parameters that are exchanged.

   Countermeasures:

   HIP uses authenticated Diffie-Hellmann key exchange, which prevents
   the man-in-the-middle (MitM) attacks.  The exchanged parameters are
   protected in the same fashion as IPSec parameters are when HIP is
   used for setting up IPSec security associations.

8.3.  Eavesdropping

   Threat:

   A possible passive attack of an adversary is placing itself between



Tschofenig, et al.       Expires April 26, 2007                [Page 20]


Internet-Draft    Using SRTP transport format with HIP      October 2006


   communication partners and collect data, that is exchanged between
   them.  As a result the adversary may learn about communciation and
   encryption details.

   Countermeasures:

   Since the data traffic is encrypted, it is unreadable for the
   attackers.

8.4.  Authentication

   Threat:

   A malicious node may impersonate another node and perform actions on
   behalf of this node for it's own needs.

   Countermeasures:

   Both peers are authenticated using asymmetric key (signature
   verification) cryptography assuming that public keys can be acquired
   by secure ways.






























Tschofenig, et al.       Expires April 26, 2007                [Page 21]


Internet-Draft    Using SRTP transport format with HIP      October 2006


9.  IANA Considerations

   This document defines several new name spaces associated with the HIP
   payloads.  This section summarizes the name spaces for which IANA is
   requested to manage the allocation of values.  IANA is requested to
   record the pre-defined values defined in the given sections for each
   name space.  IANA is also requested to manage the definition of
   additional values in the future.

   This document defines five new HIP parameters, namely SRTP_PARAM,
   SRTP_T, SRTP_RAND, SRTP_SP and SRTP_MKI.  These parameters currently
   use the experimental identifer range of the HIP protocol.  A decision
   must be made on the final values.

   The name spaces for the fields in the Security Policies parameter
   (from Section 5.4) are requested to be managed by IANA.  All proposed
   values are summarized in the tables given in this section.

   The name spaces for the fields in the Notify parameter (from Section
   5.6) are requested to be managed by IANA.































Tschofenig, et al.       Expires April 26, 2007                [Page 22]


Internet-Draft    Using SRTP transport format with HIP      October 2006


10.  Acknowledgements

   The authors would like to gratefully acknowledge Pekka Nikander and
   Jari Arkko for their comments to this document.

   This document is a byproduct of the Ambient Networks Project,
   partially funded by the European Commission under its Sixth Framework
   Programme.  It is provided "as is" and without any express or implied
   warranties, including, without limitation, the implied warranties of
   fitness for a particular purpose.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   Project or the European Commission.





































Tschofenig, et al.       Expires April 26, 2007                [Page 23]


Internet-Draft    Using SRTP transport format with HIP      October 2006


11.  References

11.1.  Normative References

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-06 (work in
              progress), June 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC3711]  Baugher, M., Carrara, E., McGrew, D., Naslund, M., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              March 2004.

11.2.  Informative References

   [I-D.ietf-hip-esp]
              Moskowitz, R., Nikander, P., and P. Jokela, "Using ESP
              transport format with HIP", draft-ietf-hip-esp-03 (work in
              progress), June 2006.

   [RFC3261]  Schulzrinne, H., Camarillo, G., Rosenberg, J., Peterson,
              J., Sparks, R., Handley, M., and E. Schooler, "Session
              Initiation Protocol", February 2005.

























Tschofenig, et al.       Expires April 26, 2007                [Page 24]


Internet-Draft    Using SRTP transport format with HIP      October 2006


Authors' Addresses

   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Phone: +49 89 636 40390
   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com


   Murugaraj Shanmugam
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: murugaraj.shanmugam@siemens.com


   Franz Muenz


   Email: franz.muenz@thirdwave.de

























Tschofenig, et al.       Expires April 26, 2007                [Page 25]


Internet-Draft    Using SRTP transport format with HIP      October 2006


Full 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.

   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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Tschofenig, et al.       Expires April 26, 2007                [Page 26]