< draft-tschofenig-hiprg-host-identities-01.txt   draft-tschofenig-hiprg-host-identities-02.txt >
HIPRG H. Tschofenig HIPRG H. Tschofenig
Internet-Draft Siemens Internet-Draft Siemens
Expires: April 4, 2005 J. Ott Expires: January 19, 2006 J. Ott
Universitaet Bremen Universitaet Bremen
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
T. Henderson T. Henderson
The Boeing Company The Boeing Company
G. Camarillo G. Camarillo
Ericsson Ericsson
October 2004 July 18, 2005
Exchanging Host Identities in SIP Interaction between SIP and HIP
draft-tschofenig-hiprg-host-identities-01.txt draft-tschofenig-hiprg-host-identities-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document proposes to exchange Host Identities (or Host Identity
Tags) in SIP/SDP for later usage in the Host Identity Protocol This document investigates the interworking between the Session
Protocol (HIP) between the SIP user agents. As such, it is a first Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and
step in investigating the interaction between SIP and HIP and mainly the benefits that may arise from their combined operation.
a discussion document.
The aspect of exchanging Host Identities (or Host Identity Tags) in
SIP/SDP for later usage with the Host Identity Protocol Protocol
(HIP) is described in more detail as an example of this interworking.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SDP Extension . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Exchanging Host Identities with SIP . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 3.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 SDP Extension . . . . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . 21 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2 Informative References . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24 8.1 Normative References . . . . . . . . . . . . . . . . . . . 23
8.2 Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 27
1. Introduction 1. Introduction
SIP [1] allows to establish and maintain sessions between two user SIP [1] enables a pair of user agents to establish and maintain
agents. The communication typically involves SIP proxies before sessions. The communication typically involves SIP proxies before
direct communication between the end points takes place. As part of prior to communication between the end points taking place. As part
the initial communication exchange a number of parameters are of the initial exchange, a number of parameters are exchanged.
exchanged including security relevant parameters, such as keying Certain of these parameters are relevant to security. Examples of
material and cryptographic information to establish a security such parameters are keying material and other cryptographic
association for subsequent data traffic protection. information that is used in order to establish a security association
for the protection of subsequent data traffic.
HIP (see [2] and [3]) creates an architecture with a new, HIP (see [2] and [3]) propose an architecture with a cryptographic
cryptographic namespace and a new layer between the network and the namespace and a layer between the network and the transport layer.
transport layer to shield applications from the impact of multi- This layer is used in order to shield applications from the impact of
homing, readdressing and mobility. A protocol, the Host Identity multi-homing, readdressing and mobility. A protocol, called the Host
Protocol, is used to establish state at the two end hosts. This Identity Protocol, is used in order to establish state at the two end
state includes the establishment of IPsec SAs. hosts. This state includes the establishment of IPsec SAs.
Several areas may benefit from the aformentioned interworking. These
include the following.
Mobility:
Mobility support can be provided at different layers in the
protocol stack. SIP can offer terminal mobility, as described in
[4]. Prior to a call, mobility is handled by re-registration with
the home registrar. For mid-call mobility, the moving node sends
a re-INVITE directly to the correspondent host, or via the SIP
proxies if, during the initial call setup, the proxy had inserted
a Record-Route header. Session mobility in SIP is implemented
through the usage of the SIP REFER method [9]. A discussion of
session mobility with SIP is, for example, provided in [10]. The
basic SIP security mechanisms are used in order to protect the
signalling exchanges that refer to the above-mentioned terminal
and session mobility.
The basic SIP mobility has two main limitations. Firstly, it is
unable to move TCP sessions to new IP addresses. This could be
accomplished by TCP extensions, such as TCP-Migrate or M-TCP or by
the usage of SCTP (where possible). The second limitation is the
low speed of handoffs.
One can shield the movement of the end hosts against each other
though the usage of HIP. HIP itself, however, does not offer
micromobility solutions or mechanisms to deal with the double-
movement problem. Extensions have been defined, such as the HIP
rendezvous concept [11] or Hi3 [12] that, among other things, deal
with initial reachability and provide additional mobility
mechanisms. A later version of this document will also
investigate the interworking of SIP with these HIP extensions. In
summary, current HIP mobility mechanisms do not offer substantial
additional features or security over what SIP provides. This
applies especially to the typical scenario where reliable
transport protocols are not used in SIP user data flows.
Middlebox Traversal:
The work on traversing Network Address Translators with SIP and
media traffic has focused on MIDCOM and the Interactive
Connectivity Establishment (ICE) methodology. ICE relies on other
protocols, such as STUN [13] and TURN [14] in order to create a
NAT binding.
HIP might be better suited for the traversal of HIP-aware NATs,
since, in this setting, the NATs can inspect the HIP signaling
exchange and create the necessary bindings. This approach is
similar to the one proposed by the NSIS working group where a
path-coupled signaling protocol is used to interact with these
middleboxes to create NAT bindings (and firewall pin-holes). The
NATFW-NSLP [15] is a protocol proposal that utilizes the NSIS
protocol suite. The travesal of HIP unaware NATs is detailed in
[16] and a discussion about NAT and firewall traversal of HIP-
aware devices is given in [17].
Denial of Service Prevention:
SIP follows the offer/answer model. The offerer generates an
offer that contains, among other things, the IP address the
answerer is expected to send its media to. The offer/answer model
can be used in order to perform denial of service attacks against
third parties. The offerer generates an offer with the IP address
of the victim and the answerer, on reception of such offer, starts
sending media to the victim. If the session consists of media
sent over a connection-oriented transport protocol such as TCP,
the victim is unlikely to respond to the connection establishment
request (e.g. the initial SYN in TCP) and the connection is not
established. However, if the session consists of media sent over
RTP and UDP, the sender just floods the victim with RTP packets.
The ICMP "not reachable" messages generated by the victim may or
may not stop the attack. Firewalls in the path may discard these
packets or the RTP library of the sender may ignore them. The use
of HIP would prevent this type of attack because the victim would
not accept the incoming HIP message. Of course, in order to
further address this type of attack no user agent in the network
should accept session descriptions that only provide IP addresses
in order to send RTP data. Sessions that did not use HIP would
need to use a different method to deal with this attack. An
example of such a method consists of using ICE (Interactive
Connectivity Establishment) [18] as a return routability test
before starting to send media. Other approaches as part of the
HIP overlay infrastructure in combination with HIP Registration
servers might also provide the same effect or even a higher degree
of security.
SRTP and HIP:
The Host Identity Protocol is able to establish IPsec security
associations, as described in [19]. In the case of SIP for voice
communication, end-to-end media protection using SRTP may be
applied. HIP supports a variety of cryptographic protection
mechanisms for the data traffic, including IPsec, SRTP. The
establishment of the necessary parameters and the keying material
for enabling SRTP communication is outlined in a separate document
[20].
Exchanging Host Identities with SIP:
HIP can benefit from existing SIP infrastructure because it
enables the distribution of Host Identities or Host Identity Tags,
as described in Section 3.
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 RFC 2119 [5].
3. Exchanging Host Identities with SIP
3.1 Concept
In order to provide security between two HIP end hosts beyond In order to provide security between two HIP end hosts beyond
opportunistic encryption it is necessary to securely retrieve the opportunistic encryption it is necessary to securely retrieve the
Host Identities. A number of mechanisms can be used including Host Identities. A number of mechanisms can be used including
directories (such as DNS) or more advanced concepts for example based directories (such as DNS) or more advanced concepts for example based
on Distributed Hash Tables typically used in peer-to-peer networks. on Distributed Hash Tables typically used in peer-to-peer networks.
This document suggests to exchange the Host Identities (or Host This document suggests to exchange the Host Identities (or Host
Identity Tags) as part of the initial SIP exchange inside the SDP Identity Tags) as part of the initial SIP exchange inside the SDP
payload. As such, the Host Identities can also be bound to the user payload. As such, the Host Identities can also be bound to the user
skipping to change at page 6, line 5 skipping to change at page 8, line 32
support. support.
The security of this approach relies on two properties: The security of this approach relies on two properties:
The signaling messages and the data traffic traverse a different The signaling messages and the data traffic traverse a different
path. Hence, an adversary needs to be located where it is able to path. Hence, an adversary needs to be located where it is able to
see both, the signaling and the the data traffic. see both, the signaling and the the data traffic.
The signaling traffic is often protected. The signaling traffic is often protected.
2. SDP Extension 3.2 SDP Extension
This document proposes to enhance the SDP [4] 'k' parameter. This document proposes to enhance the SDP [6] 'k' or 'a' parameter.
This parameter has the following structure: k=<method><encryption The 'k' parameter has the following structure:
key>. This document defines two new method fields:
k=<method>:<encryption key>
This document defines two new method fields:
k=host-identity:<HIP Host Identity> k=host-identity:<HIP Host Identity>
k=host-identity-tag:<hash of the public key> k=host-identity-tag:<hash of the public key>
Alternatively, the 'a' parameter could be used like [7] proposes. An
example for MIKEY [21] is given in the reference, which could be
reused for HIP. As defined in [22], the 'a' parameter has the
following structure:
a=<attribute>:<value>
Similar to the MIKEY example in [7], this document defines two new
method fields:
a=key-mgmt:host-identity <HIP Host Identity>
a=key-mgmt:host-identity-tag <hash of the public key>
Both, the Host Identity and the Host Identity Tag are defined in [3]. Both, the Host Identity and the Host Identity Tag are defined in [3].
The Host Identity contains the public key and a number of The Host Identity contains the public key and a number of
cryptographic parameters (such as used algorithms and Diffie-Hellmann cryptographic parameters (such as used algorithms and Diffie-Hellmann
public parameters). The Host Identity is base64 encoded. public parameters). The Host Identity is base64 encoded.
FOR DISCUSSION: FOR DISCUSSION:
The usage of the k parameter as defined in [5] is deprecated. [4] The usage of the k parameter as defined in [8] is deprecated. [6]
is more appropriate but like 'k=', they come with the caveat that is more appropriate but like 'k=', they come with the caveat that
they require a secured e2e signaling path (or SDP is S/MIME they require a secured e2e signaling path (or SDP is S/MIME
protected). One alternative is the usage of MIKEY for the protected). One alternative is the usage of MIKEY for the
exchange as defined in [6]. exchange as defined in [7].
Furthermore, and probably more important, it is important to said Furthermore, and probably more important, it is important to said
what the Host Identity is supposed to be used with. They may help what the Host Identity is supposed to be used with. They may help
avoiding re-INVITEs when underlying IP addresses change to update avoiding re-INVITEs when underlying IP addresses change to update
the 'Contact:' address as well as the addresses in the 'c=' lines the 'Contact:' address as well as the addresses in the 'c=' lines
for the various media. for the various media.
However, multiple devices may take part in the different media However, multiple devices may take part in the different media
sessions (your laptop doing video in parallel to your hardware IP sessions (your laptop doing video in parallel to your hardware IP
phone). To support these cases, it may be necessary to exchange phone). To support these cases, it may be necessary to exchange
_several_ HI(T)s within SDP and denote what they shall be used _several_ HI(T)s within SDP and denote what they shall be used
for. Such a mapping could naturally be achieved for each media for. Such a mapping could naturally be achieved for each media
stream (even using 'k=' attributes); at simple 'a=' attributes (or stream (even using 'k=' attributes); at simple 'a=' attributes (or
the mechanisms from [4]/ [6] would be preferred. the mechanisms from [6]/ [7] would be preferred.
SDP only deals with media streams and does not have a notion of SDP only deals with media streams and does not have a notion of
user or main device in the background. Hence, the SIP HI(T) may user or main device in the background. Hence, the SIP HI(T) may
need to go into SIP signaling (rather than be carried in SDP). need to go into SIP signaling (rather than be carried in SDP).
Logically, this appears to belong to the 'Contact:' header which Logically, this appears to belong to the 'Contact:' header which
may be conveyed protected in an S/MIME body (signed and may be conveyed protected in an S/MIME body (signed and
encrypted). encrypted).
3. Example 3.3 Example
This example contains the full details of the example session setup This example contains the full details of the example session setup
taken from Section 4 of [1]. The message flow is shown in Figure 1 taken from Section 4 of [1]. The message flow is shown in Figure 1
of [1] and resembles the architecture shown in Figure 1. Note that of [1] and resembles the architecture shown in Figure 1. Note that
these flows show the minimum required set of header fields; some these flows show the minimum required set of header fields; some
other header fields such as Allow and Supported would normally be other header fields such as Allow and Supported would normally be
present. present.
In our example Alice uses the following Host Identity Tag In our example Alice uses the following Host Identity Tag
(7214148E0433AFE2FA2D48003D31172E) and Bob uses (7214148E0433AFE2FA2D48003D31172E) and Bob uses
skipping to change at page 17, line 7 skipping to change at page 19, line 7
Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG Alice <- Bob: R2: {LSI(R), SPI(R), HMAC}SIG
As a result of this exchange, two IPsec SAs (one for each direction) As a result of this exchange, two IPsec SAs (one for each direction)
is established. RTP media traffic can be exchanged between the two is established. RTP media traffic can be exchanged between the two
end hosts, Alice and Bob, protected by IPsec. If end host mobility end hosts, Alice and Bob, protected by IPsec. If end host mobility
takes place then a HIP readdressing exchange takes place which is not takes place then a HIP readdressing exchange takes place which is not
detected at the upper layer by UDP/RTP or SIP. detected at the upper layer by UDP/RTP or SIP.
4. Security Considerations 4. Security Considerations
The security considerations currently deal with the proposal of
exchanging Host Identities within SIP. A future version of this
document will investigate security considerations that address other
parts of the interworking as well.
This proposal is closely aligned towards the usage of the 'k' This proposal is closely aligned towards the usage of the 'k'
parameter in SDP [5]. As a difference, an asymmetric key is parameter in SDP [8]. As a difference, an asymmetric key is
exchanged unlike the proposals illustrated in Section 6 of [5]. exchanged unlike the proposals illustrated in Section 6 of [8].
Section 5.12 of [8] is relevant for this discussion. Section 5.12 of [22] is relevant for this discussion.
If an adversary aims to impersonate one of the SIP UAs in the If an adversary aims to impersonate one of the SIP UAs in the
subsequent HIP exchange then it is necessary to replace the Host subsequent HIP exchange then it is necessary to replace the Host
Identity/Host Identity Tag exchanged in the SIP/SDP messages. Identity/Host Identity Tag exchanged in the SIP/SDP messages.
Please note that this approach is in a certain sense a re- Please note that this approach is in a certain sense a re-
instantiation of the Purpose-Built-Key (PBK) idea (see [9]). With instantiation of the Purpose-Built-Key (PBK) idea (see [23]). With
PBK a hash of a public key is sent from node A to node B. If there PBK a hash of a public key is sent from node A to node B. If there
was no adversary between A and B at that time to modify the was no adversary between A and B at that time to modify the
transmitted hash value then subsequent communication interactions transmitted hash value then subsequent communication interactions
which use the public key are secure. This proposal reuses the same which use the public key are secure. This proposal reuses the same
idea but focuses on the interworking between different protocols. In idea but focuses on the interworking between different protocols. In
fact it would be possible to use the same approach to exchange the fact it would be possible to use the same approach to exchange the
hash of an S/MIME certificate which can later be used in subsequent hash of an S/MIME certificate which can later be used in subsequent
SIP signaling message exchanges. SIP signaling message exchanges.
If Host Identities for HIP can be retrieved using a different, more If Host Identities for HIP can be retrieved using a different, more
skipping to change at page 18, line 13 skipping to change at page 20, line 13
NOT be used. NOT be used.
5. Open Issues 5. Open Issues
The authors came accross a number of open issues while thinking about The authors came accross a number of open issues while thinking about
this topic: this topic:
o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute o The authors discussed the usage of SUBSCRIBE/NOTIFY to distribute
Host Identities. This approach is particularly interesting, if Host Identities. This approach is particularly interesting, if
Host Identities are subject to frequent change. As such, it would Host Identities are subject to frequent change. As such, it would
resemble the proposal provided with SIPPING-CERT [10]. Thereby resemble the proposal provided with SIPPING-CERT [24]. Thereby
the user agent would be allowed to upload its own Host Identity to the user agent would be allowed to upload its own Host Identity to
the Credential Server. Other user agents would use the SUBSCRIBE the Credential Server. Other user agents would use the SUBSCRIBE
method to retrieve Host Identities of a particular user. With the method to retrieve Host Identities of a particular user. With the
help of the NOTIFY message it is possible to learn about a changed help of the NOTIFY message it is possible to learn about a changed
Host Identity (e.g., a revoked HI). It is for further study Host Identity (e.g., a revoked HI). It is for further study
whether this is more useful than the already described proposal. whether this is more useful than the already described proposal.
o Is an IANA registration for the method field required? o Is an IANA registration for the method field required?
o Is it possible to carry more than one Host Identity/Host Identity o Is it possible to carry more than one Host Identity/Host Identity
skipping to change at page 21, line 14 skipping to change at page 23, line 14
8. References 8. References
8.1 Normative References 8.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Moskowitz, R., "Host Identity Protocol Architecture", [2] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-06 (work in progress), June 2004. draft-ietf-hip-arch-02 (work in progress), January 2005.
[3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-00 [3] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03
(work in progress), June 2004. (work in progress), June 2005.
[4] Andreasen, F., Baugher, M., and D. Wing, "Session Description [4] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
Protocol Security Descriptions for Media Streams", using SIP, ACM MC2R", , July 2000.
draft-ietf-mmusic-sdescriptions-07 (work in progress),
July 2004.
[5] Handley, M. and V. Jacobson, "SDP: Session Description [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Protocol", RFC 2327, April 1998. Levels", March 1997.
[6] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [6] Andreasen, F., "Session Description Protocol Security
Norrman, "Key Management Extensions for Session Description Descriptions for Media Streams",
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-sdescriptions-11 (work in progress),
draft-ietf-mmusic-kmgmt-ext-11 (work in progress), April 2004. June 2005.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [7] Arkko, J., "Key Management Extensions for Session Description
Levels", March 1997. Protocol (SDP) and Real Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-kmgmt-ext-15 (work in progress), June 2005.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
8.2 Informative References 8.2 Informative References
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in Method", RFC 3515, April 2003.
progress), September 2004.
[9] Bradner, S., Mankin, A., and J. Schiller, "A Framework for [10] Shacham, R., "Session Initiation Protocol (SIP) Session
Mobility", draft-shacham-sipping-session-mobility-01 (work in
progress), July 2005.
[11] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-03 (work in
progress), July 2005.
[12] Nikander, P., "Host Identity Indirection Infrastructure (Hi3)",
draft-nikander-hiprg-hi3-00 (work in progress), June 2004.
[13] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-01
(work in progress), February 2005.
[14] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-07 (work in progress),
February 2005.
[15] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
May 2005.
[16] Stiemerling, M., "Middlebox Traversal Issues of Host Identity
Protocol (HIP) Communication", draft-stiemerling-hip-nat-05
(work in progress), July 2005.
[17] Tschofenig, H., "NAT and Firewall Traversal for HIP",
draft-tschofenig-hiprg-hip-natfw-traversal-01 (work in
progress), February 2005.
[18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-04 (work in progress), February 2005.
[19] Jokela, P., "Using ESP transport format with HIP",
draft-ietf-hip-esp-00 (work in progress), July 2005.
[20] Tschofenig, H., "Using SRTP transport format with HIP",
draft-tschofenig-hiprg-hip-srtp-00 (work in progress),
July 2005.
[21] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[22] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.
[23] Bradner, S., Mankin, A., and J. Schiller, "A Framework for
Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 (work in
progress), June 2003. progress), June 2003.
[10] Jennings, C., "Certificate Management Service for SIP", [24] Jennings, C. and J. Peterson, "Certificate Management Service
draft-jennings-sipping-certs-04 (work in progress), July 2004. for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-01 (work in progress), February 2005.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
skipping to change at page 24, line 41 skipping to change at page 27, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 32 change blocks. 
76 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/