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]