< draft-wing-sipping-srtp-key-00.txt   draft-wing-sipping-srtp-key-01.txt >
Network Working Group D. Wing Network Working Group D. Wing
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track F. Audet Intended status: Standards Track F. Audet
Expires: August 21, 2007 Nortel Expires: January 9, 2008 Nortel
S. Fries S. Fries
Siemens AG Siemens AG
H. Tschofenig H. Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
February 17, 2007 July 8, 2007
Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package
draft-wing-sipping-srtp-key-00 draft-wing-sipping-srtp-key-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 21, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Many Secure RTP (SRTP) key exchange mechanisms do not disclose the Many Secure RTP (SRTP) key exchange mechanisms do not disclose the
SRTP session keys to intermediate SIP proxies. However, these key SRTP session keys to intermediate SIP proxies. Howevr, these key
exchange mechanisms cannot be used In environments where transcoding, exchange mechanisms cannot be used In environments where transcoding,
monitoring, or call recording are needed. This document specifies a monitoring, or call recording are needed. This document specifies a
secure mechanism for a cooperating endpoint to disclose its SRTP secure mechanism for a cooperating endpoint to disclose its SRTP
master keys to an authorized party. master keys to an authorized party.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Learning Name and Certificate of ESC . . . . . . . . . . . 5 3.1. Learning Name and Certificate of ESC . . . . . . . . . . . 5
3.2. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 5 3.2. Authorization of ESC . . . . . . . . . . . . . . . . . . . 5
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Sending SRTP Session Keys to ESC . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3.4. Scenarios and Call Flows . . . . . . . . . . . . . . . . . 7
5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 6 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 7 5.1. Incorrect ESC . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Integrity and encryption of keying information . . . . . . 7 5.2. Risks of Sharing SRTP Session Key . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.3. Disclosure Flag . . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Integrity and encryption of keying information . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informational References . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 8.2. Informational References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
This document addresses 2 difficulties with end-to-end encryption of This document addresses 2 difficulties with End-to-end encryption of
RTP (SRTP [RFC3711]): transcoding and media recording. When peering RTP (SRTP [RFC3711]): transcoding and media recording. When peering
with other networks, different codecs are sometimes necessary with other networks, different codecs are sometimes necessary
(transcoding a surround-sound codec for transmission over a highly- (transcoding a surround-sound codec for transmission over a highly-
compressed bandwidth-constrained network, for example). In some compressed bandwidth-constrained network, for example). In some
environments (e.g., stock brokerages and banks) regulations and environments (e.g., stock brokerages and banks) regulations and
business needs require recording calls with coworkers or with business needs require recording calls with coworkers or with
customers. In many environments, quality problems such as echo can customers. In many environments, quality problems such as echo can
only be diagnosed by listening to the call (analyzing SRTP headers is only be diagnosed by listening to the call (analyzing SRTP headers is
not sufficient). not sufficient).
skipping to change at page 4, line 11 skipping to change at page 4, line 11
This document describes cases (2) and (3) where a cooperating This document describes cases (2) and (3) where a cooperating
endpoints publishes its SRTP master keys to an authorized party using endpoints publishes its SRTP master keys to an authorized party using
the SIP Event State Publication Extension [RFC3903]. The mechanism the SIP Event State Publication Extension [RFC3903]. The mechanism
described in this paper allows secure disclosure of SRTP session keys described in this paper allows secure disclosure of SRTP session keys
to authorized parties so that an endpoints media stream can be to authorized parties so that an endpoints media stream can be
transcoded or decrypted, as needed by that environment. transcoded or decrypted, as needed by that environment.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The following terminology is taken directly from SIP Event State The following terminology is taken directly from SIP Event State
Publication Extension [RFC3903]: Publication Extension [RFC3903]:
Event Publication Agent (EPA): The User Agent Client (UAC) that Event Publication Agent (EPA): The User Agent Client (UAC) that
issues PUBLISH requests to publish event state. issues PUBLISH requests to publish event state.
Event State Compositor (ESC): The User Agent Server (UAS) that Event State Compositor (ESC): The User Agent Server (UAS) that
skipping to change at page 5, line 16 skipping to change at page 5, line 16
The endpoint will be configured with the AOR of its ESC (e.g., The endpoint will be configured with the AOR of its ESC (e.g.,
"transcoder@example.com"). If S/MIME is used to send the SRTP master "transcoder@example.com"). If S/MIME is used to send the SRTP master
key to the ESC, the endpoint is additionally configured with the key to the ESC, the endpoint is additionally configured with the
certificate of its ESC. certificate of its ESC.
This configuration is outside the scope of this document, but some This configuration is outside the scope of this document, but some
examples are CLI, [I-D.ietf-sipping-config-framework], or examples are CLI, [I-D.ietf-sipping-config-framework], or
[I-D.ietf-sip-certs]. [I-D.ietf-sip-certs].
3.2. Sending SRTP Session Keys to ESC 3.2. Authorization of ESC
Depending on the application, authorization of the key disclosure and
distribution to the ESC may be necessary besides the pure transport
security of the key distribution itself. This may be the case when
the config framework [I-D.ietf-sipping-config-framework] is not
applied and thus the information about the ESC is not known to the
client.
This can be done by providing a SAML extension, according to
[I-D.ietf-sip-saml] in the header of the SUBSCRIBE message. The SAML
assertion shall at least contain the information about the ESC, call
related information to associate the call with the assertion (editors
note: we may also define wildcards here to allow for recordings of
all phone calls for a day, independent of the call) and a reference
to the certificate for the ESC. The latter information is needed to
transport the SRTP Session Key to the ESC in a protected manner, as
described in the section below.
The signature of the SAML assertion should be produced using the
private key of the domain certificate. This certificate MUST have a
SubjAltName which matches the domain of user agent's SIP proxy (that
is, if the SIP proxy is sip.example.com, the SubjAltName of the
domain certificate signing this SAML assertion MUST also be
example.com). Here, the main focus is placed on communication of
clients with the ESC, which belongs to the client's home domain.
3.3. Sending SRTP Session Keys to ESC
SDP is used to describe the media session to the ESC. However, the SDP is used to describe the media session to the ESC. However, the
existing Security Descriptions [RFC4568] only describes the master existing Security Descriptions [RFC4568] only describes the master
key and parameters of the SRTP packets being sent -- it does not key and parameters of the SRTP packets being sent -- it does not
describe the master key (and parameters) of the SRTP being received, describe the master key (and parameters) of the SRTP being received,
or the SSRC being transmitted. For transcoding and media recording, or the SSRC being transmitted. For transcoding and media recording,
both the sending key and receiving key are needed and in some cases both the sending key and receiving key are needed and in some cases
the SSRC is needed. the SSRC is needed.
Thus, we hereby extend the existing crypto attribute to indicate the Thus, we hereby extend the existing crypto attribute to indicate the
skipping to change at page 6, line 35 skipping to change at page 7, line 22
inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32 inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32
192.0.2.222:2893 192.0.2.222:2893
a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32
inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32 inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32
192.0.2.222:2893 192.0.2.222:2893
Figure 2: Strawman solution Figure 2: Strawman solution
]] ]]
3.4. Scenarios and Call Flows
The following scenarios and call flows depict the assumptions for the
provision of media key disclosure. Figure 3 shows the general setup
within the home domain of the client. Note that the authors assume
that the client only discloses media keys only to an entity in the
client's home network rather than to an arbitrary entity in the
visited network.
+--------+ +-------+ +-------+ +--------+
| Client | | Proxy | | ESC | | MedRec |
+--------+ +-------+ +-------+ +--------+
| | | |
+---------------+--------------+--------------+
Figure 3: Network Topology
Based on this setup there are different options to realize the key
disclosure, depending on the environment. In the following two
approaches are distingusihed.
Publishing media keys to the ESC
This requires that the configuration management provides the ESC
configuration data (e.g., certificate, policy) in a secure way to
the client. As stated above, this configuration is outside the
scope of this document, but an example can be found in
[I-D.ietf-sipping-config-framework]. The key disclosure in this
approach uses the PUBLISH method to disclose the key to the ESC
according to a given policy.
+--------+ +-------+ +-------+ +--------+
| Client | | Proxy | | ESC | | MedRec |
+--------+ +-------+ +-------+ +--------+
| | | |
| - REGISTER -> | | |
| <- 200 OK -- | | |
| | | |
| -- INVITE --> | | |
| <- 200 OK -- | | |
| | | |
| -- PUBLISH (Key Data) --> | |
| | | |
Using SAML assertions for ESC contact
In this approach authorization is provided via a SAML assertion,
see [I-D.ietf-sip-saml], indicating which ESC is allowed to
perform call recording of a single or a set of calls, depending on
the content of the assertion. Here a SAML assertion is provided
as part of the SUBSCRIBE message, send from the ESC to the client.
The assertion needs to provide at least the call relation, or a
time intervall for which media recoding is going to be performed.
The SAML assertion is signed with the private key associated with
the domain certificate, which is in possession of the
authentication service. The call flow would look like following:
+--------+ +-------+ +-------+ +--------+
| Client | | Proxy | | ESC | | MedRec |
+--------+ +-------+ +-------+ +--------+
| | | |
| - REGISTER -> | | |
| <- 200 OK -- | | |
| | | |
| <- SUBSCIBE (call forming) - | |
| + SAML assertion | |
| | | |
| -- INVITE --> | | |
| <- 200 OK -- | | |
| | | |
| -- NOTIFY (Key Data) --> | |
4. Grammar 4. Grammar
[[Grammar will be provided in a subsequent version of this [[Grammar will be provided in a subsequent version of this
document.]] document.]]
5. Security Considerations 5. Security Considerations
5.1. Incorrect ESC 5.1. Incorrect ESC
Insertion of the incorrect public key of the SRTP ESC will result in Insertion of the incorrect public key of the SRTP ESC will result in
skipping to change at page 7, line 25 skipping to change at page 9, line 42
5.3. Disclosure Flag 5.3. Disclosure Flag
Secure SRTP key exchange techniques which implement this Secure SRTP key exchange techniques which implement this
specification SHOULD provide a "disclosure flag", similar to that specification SHOULD provide a "disclosure flag", similar to that
first proposed in Appendix B of [I-D.zimmermann-avt-zrtp]. first proposed in Appendix B of [I-D.zimmermann-avt-zrtp].
5.4. Integrity and encryption of keying information 5.4. Integrity and encryption of keying information
The mechanism describe in this specification relies on protecting and The mechanism describe in this specification relies on protecting and
encrypting the keying information. There are well known mechanism to encrypting the keying infomation. There are well known mechanism to
achieve that goal. achieve that goal.
Using SIPS to convey the SRTP key exposes the SRTP master key to all Using SIPS to convey the SRTP key exposes the SRTP master key to all
SIP proxies between the Event Publication Agent (ESC, the SIP User SIP proxies between the Event Publication Agent (ESC, the SIP User
Agent) and the Event State Compositor (ESC). S/MIME allows Agent) and the Event State Compositor (ESC). S/MIME allows
disclosing the SRTP master key to only the ESC. disclosing the SRTP master key to only the ESC.
6. IANA Considerations 6. IANA Considerations
New SSRC extension of the "crypto" attribute, and the new "rcrypto" New SSRC extension of the "crypto" attribute, and the new "rcrypto"
skipping to change at page 8, line 35 skipping to change at page 10, line 40
s=- s=-
c=IN IP4 192.0.2.101 c=IN IP4 192.0.2.101
t=0 0 t=0 0
m=audio 49172 RTP/SAVP 0 m=audio 49172 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 a=rcrypto:1 AES_CM_128_HMAC_SHA1_32
inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
Figure 3: Example with "SIPS:" AOR Figure 6: Example with "SIPS:" AOR
This is an example showing an S/MIME-encrypted transmission to the This is an example showing an S/MIME-encrypted transmission to the
media recorder's AOR, recorder@example.com. The data enclosed in "*" media recorder's AOR, recorder@example.com. The data enclosed in "*"
is encrypted with recorder@example.com's public key. is encrypted with recorder@example.com's public key.
PUBLISH sip:recorder@example.com SIP/2.0 PUBLISH sip:recorder@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:recorder@example.com> To: <sip:recorder@example.com>
From: <sip:dan@example.com>;tag=1234wxyz From: <sip:dan@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com Call-ID: 81818181@pua.example.com
skipping to change at page 9, line 44 skipping to change at page 11, line 44
* t=0 0 * * t=0 0 *
* m=audio 49172 RTP/SAVP 0 * * m=audio 49172 RTP/SAVP 0 *
* a=crypto:1 AES_CM_128_HMAC_SHA1_32 * * a=crypto:1 AES_CM_128_HMAC_SHA1_32 *
* inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 * * inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 *
* a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 * * a=rcrypto:1 AES_CM_128_HMAC_SHA1_32 *
* inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 * * inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 *
* a=rtpmap:0 PCMU/8000 * * a=rtpmap:0 PCMU/8000 *
* * * *
****************************************************************** ******************************************************************
Figure 4: Example with S/MIME-encrypted SDP Figure 7: Example with S/MIME-encrypted SDP
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
skipping to change at page 10, line 35 skipping to change at page 12, line 35
SIP", draft-wing-rtpsec-keying-eval-02 (work in progress), SIP", draft-wing-rtpsec-keying-eval-02 (work in progress),
February 2007. February 2007.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-10 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
January 2007. June 2007.
[I-D.ietf-sip-sips] [I-D.ietf-sip-sips]
Audet, F., "Guidelines for the use of the SIPS URI Scheme Audet, F., "The use of the SIPS URI Scheme in the Session
in the Session Initiation Protocol (SIP)", Initiation Protocol (SIP)", draft-ietf-sip-sips-05 (work
draft-ietf-sip-sips-01 (work in progress), February 2007. in progress), June 2007.
[I-D.ietf-sip-certs] [I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The Jennings, C., "Certificate Management Service for The
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-02 (work in progress), October 2006. draft-ietf-sip-certs-03 (work in progress), March 2007.
[I-D.ietf-sip-saml]
Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-02 (work in progress), May 2007.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., "ZRTP: Extensions to RTP for Diffie- Zimmermann, P., "ZRTP: Media Path Key Agreement for Secure
Hellman Key Agreement for SRTP", RTP", draft-zimmermann-avt-zrtp-03 (work in progress),
draft-zimmermann-avt-zrtp-02 (work in progress), March 2007.
October 2006.
[RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van
Wijk, "Transcoding Services Invocation in the Session Wijk, "Transcoding Services Invocation in the Session
Initiation Protocol (SIP) Using Third Party Call Control Initiation Protocol (SIP) Using Third Party Call Control
(3pcc)", RFC 4117, June 2005. (3pcc)", RFC 4117, June 2005.
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
Francois Audet Francois Audet
Nortel Nortel
4655 Great America Parkway 4655 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
skipping to change at page 11, line 37 skipping to change at page 13, line 40
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: steffen.fries@siemens.com Email: steffen.fries@siemens.com
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 20 change blocks. 
39 lines changed or deleted 144 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/