wdiff draft-tschofenig-hiprg-hip-srtp-00.txt draft-tschofenig-hiprg-hip-srtp-01.txt

HIPRG H. Tschofenig
Internet-Draft Siemens
Expires: January 12, April 26, 2006 F. Muenz
FH-Landshut
M. Shanmugam
TUHH
July 11,
October 23, 2005

Using SRTP transport format with HIP
draft-tschofenig-hiprg-hip-srtp-00.txt
draft-tschofenig-hiprg-hip-srtp-01.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 January 12, April 26, 2006.

Abstract

The Host Identity Protocol (HIP) is a signaling protocol which adds another a
new layer to between the Internet model traditional Transport and (optionally) establishes IPsec ESP
SAs to protect subsequent data traffic. 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 genralized and purported to support different key
exchange mechanisms in order to provide confidentiality protection
for the subsequent data traffic. In some cases it might not be
desirable to establish IPsec security associations for protection of
media traffic. This draft explains a how keying material and
parameters for usage with the Secure Real Time Protocol (SRTP) based mechanism for transmission of user data
packets, to can be used with the Host Identity Protocol (HIP).
established using HIP.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Flow Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Base Exchange
4. The Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. SRTP in HIP . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Setting up an SRTP Association . . . . . . . . . . . . 7
3.2
4.1.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . 8
5. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 9
5.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Packet Format
5.2. Pseudo-random byte-string (RAND) . . . . . . . . . . . . . 9
5.3. Security Policies (SP) . . . . . . . . . . . . . . . . . . 10
4.
5.4. Master Key Identifier (MKI) . . . . . . . . . . . . . . . 12
6. Key management . . . . . . . . . . . . . . . . . . . . . . . . 13
5.
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
6.2 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 . . 20

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 .
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 [I-D.ietf-hip-multi6].

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 and (optionally) establishes IPsec SAs to
protect subsequent data traffic. It is a four-way handshake
protocol, which supports end-to-end authentication and the data
traffic may experience IPsec ESP encapsulation. Since different
sizes for the public key are possible, it uses the Host Identity Tag
(HIT), which is the hash of the public key, for operational
representation. The HIP header carries HIT (128 bits long), which is
similar to IPV6 addresses.

Transport connections and Security Associations security associations between the
communicating HIP hosts are bound to the HITs only. and IP addresses are
used for routing purposes only. Therefore, changes to IP addresses
do not change the connections or associations. So, when any of the
peers move, move (mobility scenarios), it uses a readdressing mechanism to
update the current location of the peer, thereby supporting mobility
in a seamless manner.

Session Initiation Protocol (SIP) is an application layer protocol,
which is capable of establishing modifying and terminating sessions
between the hosts.

The SIP architecture uses URIs to uniquely
identify (maps) the user agents and has various infrastructure
components like proxy server, redirect server etc., to achieve
personal mobility.

SIP, when combined with RTP, can effectively handle multimedia
applications. SIP can also invite participants to already existing
sessions, such as multicast conferences. Media can be added to (and
removed from) an existing session. SIP relies on other security
protocols like TLS, IPsec, HTTP Digest mechanisms to protect the SIP
traffic.

HIP base exchange [I-D.ietf-hip-base] does not describe any transport
formats for user data. This document proposes extensions to HIP by
exporting the relevant parameters to support other key management
scheme, like MIKEY. SRTP proposes MIKEY [RFC3830] as a key
management protocol. We propose to use the same key management
scheme in HIP. HIP combined with MIKEY alike scheme can be used for
SRTP as a key management protocol to exchange Master Keys and create
a Cryptographic Context (SRTP RFC chapter 3.2). HIP has to satisfy
the requirements of SRTP (SRTP RFC chapter 7/8) for a key management
protocol and has to support the appropriate cryptographic algorithms
within its transform parameters. HIP base exchange provides a mutual authentication of the hosts,
but does not specify any mechanism for protecting data packets for the
actual communication. packets.
[I-D.ietf-hip-esp] draft proposes a way to use IPsec ESP format with
HIP. In this document, we specify the use of
SRTP

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 protecting user data traffic after the HIP base exchange. real-time data traffic.

SRTP mandates the use of a external key management protocol (like
MIKEY) 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 the SRTP relevant parameters during the HIP base
exchange. Besides this, we inherited the key derivation procedure of
SRTP to show how the keys will be manipulated and maintained for the
data traffic. Appendix A describes one possible use case to support
this document.

This document explains the compatibility of HIP and SIP together with
the new KEY management scheme. is organized as follows. Section 3 explains the
revised base exchange, and Section 4 explains the rekeying scenario,
Section 5 presents the packet format and Section 6 explains the key derivation
derivation, and future work.

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

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 used uses the terminology defined in [I-D.ietf-hip-base] and
[RFC3261].

The term MKI MKI, an optionl parameter, refers to Master Key Identifier
used in SRTP packets.
It is similar to SPIs in IPsec.

3. Message Flow

This section explains the integration of SIP and HIP. Goal

The motivation
to combine HIP and SIP base exchange is defined in [I-D.ietf-hip-sip]. SIP uses
URIs, which bind used to an IP address or set up a host name. When HIP is used,
SIP headers will make use of HITs instead of IPs i.e, SIP URIs will
be bound to HITs. A HIT is derived from HI (public key), which
identify users/hosts and IP addresses. association between two
hosts. The resolution of IP from HI/
HITs can be done via DNS or other mechanisms. Also, the HI/HITs can
be exchanged using SIP/SDP mechanism as desribed in [I-D.ietf-hip-
sip].

Initially the caller sends an INVITE message to its proxy server,
assuming that the caller is already connected. Then the caller proxy
server locates the callee proxy server, possibly by performing a
particular type of DNS (Domain Name Service) lookup (DNS SRV record).
DNS will return base exchange provides two-way host authentication and
key material generation, but it does not provide any means for
protecting data communication between the HI/HIT of hosts. In this document,
we specify the callee together with one or more IP
addresses use of SIP proxies responsible SRTP for protecting user data traffic after the callee. After
resolution it forwards
HIP base exchange. Note that we did not consider the message to a callee proxy server and adds
a new entry key management
issues in this draft.

To facilitate the SIP header (for route record routability). The
callee proxy receiving the INVITE message consults a location
database via a location service to resolve the HIT use of SRTP, the callee to
current IP address. Finally, it forwards the INVITE to the callee.

There are several ways how to combine SIP messages with HIP base-
exchange. SIP and HIP base exchange messages could be combined require
some minor additions to reduce
roundtrips or can be used separately.The latter will be explained in
detail in this section.

+---------+
+------+ |HIP RVS | +------+
|Caller| |Callee | |Callee|
+------+ +---------+ +------+
| | |
+-------------------I1-------------->+-------I1--------->|
|<------------------R1-----------------------------------+
+-------------------I2---------------------------------->|
|<------------------R2-----------------------------------+
| | |
|<==================TCP/UDP Session=====================>|

Figure 1: SIP and HIP Base Exchange

Session establishment works in known ways. First an INVITE is routed
from the caller parameters transported. In the R1
packet, the responder adds the possible KEYING Parameter before
sending it to the callee using SIP proxies. Initiator. The callee then
answers with 200 OK and Initiator gets the caller acknowledges with an ACK message
directly proposed
transforms, selects one of those proposed transforms, and adds it to
the callee. However I2 packet in the corresponding KEYING Parameter.

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

o define new parameter exchange for the SIP
signalling traffic will not include any relevant SRTP parameters (transforms),
which will be decoupled parameters.

o define the relevant packets structure and delegated to HIP. SIP only serves as a
rendezvous parameters.

4. The Protocol

In this section, the protocol for HIP setting up an SRTP association to exchange end-host IP addresses and
negotiate HIP as the
be used end-to-end authentication and key exchange
protocol.

3.1 Base Exchange

After with HIP association is chosen there are again two possibilities on how to
proceed. Firstly described.

4.1. SRTP in HIP base-exchange may run directly

4.1.1. Setting up an SRTP Association

Setting up an SRTP Association between
communication partners or secondly the callee might be hosts using HIP
rendezvous server which is shown in figure 1.

As explained in the previous sections, HIP allows the use consists of other
key management protocols. Figure 2 explains how
two messages passed between the new KEYING hosts. The parameters fit into the HIP are included
in R1 and I2 messages during base exchange: exchange.

Initiator Responder

I1: ------Trigger exchange--------------------------------->
I1
---------------------------------->
R1: <------ puzzle{HI(R),DH(R)}sig(R)------------------------

I2: -{Soln,DH(I), T, KEYING param.,MKI, enc{HI}keymat }sig(I)->

R2: <------ { PARAMS
<----------------------------------
I2: T, KEYING param.,MKI, HMAC }sig(R) ---------------

Fig 2: Base Exchange PARAMS
---------------------------------->
R2
<----------------------------------

The Initiator starts the HIP connection by sending the trigger
message. This message is nothing but two IPs and HITs integration of the
Initiator and the Responder respectively. The Responder answers with
the R1 packet, the difference between the actual HIP exchange and the
proposed mechanism is the removal of the cipher suites, because the
transforms will be chosen via KEYING parameter. Since we have to
avoid the state creation, it sends a precomputed packet.

Context id = <SSRC, destination HIT/address, destination port> This
triple SHALL uniquely identiies a cryptographic context (SRTP RFC
chapter 3.2.3.). This context id together with MKI will be mapped to
the master key and cipher suites SRTP requires some changes, as mentioned
earlier, in KEYING management scheme to find the session keys HIP parameters. The changes are (will be) adding,

T: The timestamp, used mainly to process the packet.

Any specific transform parameters needed for the SRTP cryptographic
context will be exchanged by using SP parameter of prevent replay attacks.

KEYING parameter
in HIP.

Master Key - derived from Diffie-Hellmann contains

RAND: Random/pseudo-random byte-string, RAND(nonce) is used as a
fresh value

Master Salt - RAND in the KEYING parameter

MKI - Master Key Identifier

Upon receiving it , for the Initiator solves key generation.

SP: The security policies for the puzzle data security protocol. (eg.
Algorithms and sends the I2
packet with the Diffie Hellmann value transforms and its KEYING parameter. For
the explanation of KEYING parameter see above. The Initiator's HI is
encrypted PRFs supported by the keying material derived peers). The
cipher suites can be negotiated from R1/I2 packet.

MKI : to identify the master Master key (Diffie
Hellmann value), so that and Master salt.

The R1 message contains the responder can also derive KEYING PARAMS, in which the same key
using sending host
defines the negotiated cipher suites possible Algorithms and Diffie Hellmann value to
decrypt the HI. The key management transforms, random number and key derivation
optionally MKI it is up willing to use for the
KEY scheme. The whole packet is signed by the Initiator's public
key. SRTP association.

The Responder receives the packet verifies the solution, derives the
key using the Diffie Hellmann value and I2 message contains the response to an KEYING parameter,
decrypts the HI, using the keying material , and verifies PARAMS received in
the
Signature. R1 message. The Responder derives all sender must select one of the encryption and
authentication keys proposed
transforms from the Initiator's master (Diffie Hellmann) and
salt key (KEYING SP parameter RAND). The reason for this is that both in the Initiator R1 message and Responder have the same key pairs for providing
confidentiality for the data traffic.

Next, the Responder sends its KEYING parameter , the same time stamp,
random no, include the
selected cipher suites and HMAC of the whole packet, one in the key for HMAC is derived from SP parameter in the Master Key. It sends its MKI I2 packet. In addition to
identify
the incoming packet. The Initiator will check transform, the HMAC and
also host includes the Signature to verify RAND parameter, containing the integrity and authenticity of
random value (and optionally MKI) to be used as a salt by the
packet. After this, peer
host. In the R2 message, HIP association is established and both the
hosts use their respective master key and it derived keys for
protecting the traffic. The Master Key exchange is 128 bit long, which can be
exchanged using the Diffie Hellmann parameter.

3.2 finalized.

4.1.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 -Update([seq,REA],DH(R),KEYING param., MKI,HMAC)Sig(I) ----->

Seq <-Update seq([ack, REA],DH(I),KEYING param.,MKI,HMAC)Sig(R)-

Update ---------------Update ACK( ack, HMAC)Sig(I)----------------->
ACK

UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN]
----------------------------------------------->
UPDATE: KEYING PARAMS [, DIFFIE_HELLMAN]
<-----------------------------------------------
Fig 3:Rekeying 2:Rekeying mechanism

Figure 3 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. The same mechanism is
followed here, the Initiator chooses its Diffie Hellmann Diffie-Hellmann value and
sends it to the Responder. The key for HMAC has been derived from
the old Master key. It also sends may send a new MKI value to identify
the incoming packet.

The Responder chooses its Diffie Hellmann value, verifies the HMAC
and Signature. The other parameters are explained in [I-D.ietf-hip-
base] draft. [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 concluding the rekeying procedure and
now, both of the peers expect to receive the traffic in the new
keying material.

3.3

5. Parameter and Packet Format Formats

This section explains the packet format for relationship between the SRTP and KEYING
parameter and presents the proposed packet format.

Master Key - derived from Diffie-Hellmann value

Master Salt - RAND in
more detail. the KEYING parameter

MKI - Master Key Identifier

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

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

As discussed previously, KEYING parameters contains

T: four element:

5.1. Timestamp

The timestamp, used mainly to prevent replay attacks.

RAND: Random/pseudo-random byte-string, RAND(nonce) Like in the
SRTP packet format a 32-bit value is used to store the timestamp.

Fig 4: Timestamp parameter

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

5.2. Pseudo-random byte-string (RAND)

The RAND or master salt parameter is used as a
freshness fresh value for the
key generation (salts).

SP: generation. The RAND parameter is a 112 bit quantity.

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.3. Security Policies (SP)

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

MKI : It is similar to SPI i.e, to identify the Master key and
also security associations.

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

session keys is derived using Master key and SP

Fig 6: Security policy parameters parameters

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

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

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRTP prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Type | SRTP-packets-max-lifetime Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

Type | Key derivation rate Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Meaning | SRTCP-packets-max-lifetime Value
-----+--------+----------------------------+--------------------
1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fig 4: Key management parameters

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

SRTP and SRTCP encr transf. transf | Value
---------------------------------
---------------------------+------
NULL | 0
AES_CM
AES-CM | 1
AES_f8
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. transf | Value
---------------------------------
----------------------------+------
NULL | 0
HMAC-SHA1
HMAC-SHA-1 | 1

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.4. Master Key Identifier (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.

Fig 5: 7: SRTP MKI parameter

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

6. Key management

This section explains how the key management scheme can be used for
the data traffic. 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 packet.

The SRTP based key derivation helps to generate the session keys for
both peers, so that they have the same keys in possession for
encrypting/decrypting the incoming packets. It generates three keys
namely encryption key to provide confidentiality for the data
packets, authentication key for providing integrity and salt key for
the AES counter mode. For that, it uses the master key, salt and
crypto transforms together with the packet index.

Figure 6 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 |
+--------------+

Fig 6: 5: Example Implementation Architecture

Figure 7 6 depicts the key derivation, for example, when the peer
receives a packet it gets the packet index, MKI, which is used for
identifying the relevant master key and transforms. Then, the key
derivation function, which is explained below, will generate the
required keys.

packet index ---+
|
v
+-----------+ master +--------+ session encr_key
| ext | key | |---------->
| key mgmt |-------->| key | session auth_key
| (optional | | deriv |---------->
| rekey) |-------->| | session salt_key
| | master | |---------->
+-----------+ salt +--------+

Fig 7: 6: SRTP Key Derivation

For single key derivation (key_derivation_rate = 0), we define x for
later use in calculating keys using PRF and length of PRF bit string
output like shown in the following table:

X ROC || SEQ Usage PRF output length n
---------------------------------------------------------------
0x00 000000000000 SRTP encryption 128 bit
0x01 000000000000 SRTP message auth. 160 bit
0x02 000000000000 SRTP salting key 112 bit
0x03 000000000000 SRTCP encryption 128 bit
0x04 000000000000 SRTCP message auth. 160 bit
0x05 000000000000 SRTCP salting key 112 bit
PRF_n (master_key, x)

For multiple key derivation (key_derivation_rate = 1,2,...2E24)
x must be calculated according to the following sequence:

r = index / key_derivation_rate
(with "/" defines r = 0 for key_derivation_rate = 0)

with index is a 48-bit concatenation of the 32 bit Roll Over Counter
(ROC) and the 16 bit sequence number of the SRTP packet given in the
SRTP header (ROC||SEQ)

r must be the same length like index, which results in leading zeros.

Next concatenate an 8-bit label for selecting the usage with r
key_id = <label> concatenated with r.

where <label> is one of the following>
0x00 for SRTP encryption
0x01 for SRTP message authentication
0x02 for SRTP salting key
0x03 for SRTCP encryption key
0x04 for SRTCP authentication key
0x05 for SRTCP salting key

Finally, x is calculated by performing key_id XOR master_salt,
where key_id and master_salt are aligned so that their least
significant bits agree (right-alignment).

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

DoS: 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.

MitM: HIP uses authenticated Diffie-Hellmann key exchange, which
prevents the man-in-the-middle (MitM) attacks.

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

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

8. Acknowledgements

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

9. References

6.1

9.1. Normative References

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

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

6.2

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

9.2. Informative References

[I-D.ietf-hip-esp]
Moskowitz, R., Nikander, P., and P. Jokela, "Host Identity
Protocol", draft-ietf-hip-esp-00 (work in progress),
June 2005.

[I-D.ietf-hip-multi6]
Tschofenig, H. and A. Nagarajan, "Comparative Analysis of
Multi6 Proposals using a Locator/Identifier Split",
October 2004.

[I-D.ietf-hip-sip]
Tschofenig, H., Schulzrinne, H., Henderson, T., Torvinen,
V., Camarillo, G., and J. ott, "Exchanging Host Identities
in SIP", October 2004.

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

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

[RFC3830] Arrko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing",
draft-ietf-hip-base-02 (work in progress), August 2004.

Authors' Addresses

Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany

Email: Hannes.Tschofenig@siemens.com

Franz Muenz
University of Applied Sciences
Lurzenhof 1
Landshut, Bayern 84036
Germany

Email: franz.muenz@fh-landshut.de

Murugaraj Shanmugam
Technical University Hamburg-Harburg
Schwarzenbergstrasse 95
Harburg, Hamburg 21075
Germany

Email: murugaraj.shanmugam@tuhh.de

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 (C) The Internet Society (2005). 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.