draft-ietf-sip-media-security-requirements-08.txt   draft-ietf-sip-media-security-requirements-09.txt 
SIP Working Group D. Wing, Ed. SIP Working Group D. Wing, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational S. Fries Intended status: Informational S. Fries
Expires: May 3, 2009 Siemens AG Expires: July 13, 2009 Siemens AG
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
F. Audet F. Audet
Nortel Nortel
October 30, 2008 January 9, 2009
Requirements and Analysis of Media Security Management Protocols Requirements and Analysis of Media Security Management Protocols
draft-ietf-sip-media-security-requirements-08 draft-ietf-sip-media-security-requirements-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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 May 3, 2009. This Internet-Draft will expire on July 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes requirements for a protocol to negotiate a This document describes requirements for a protocol to negotiate a
security context for SIP-signaled SRTP media. In addition to the security context for SIP-signaled SRTP media. In addition to the
natural security requirements, this negotiation protocol must natural security requirements, this negotiation protocol must
interoperate well with SIP in certain ways. A number of proposals interoperate well with SIP in certain ways. A number of proposals
have been published and a summary of these proposals is in the have been published and a summary of these proposals is in the
appendix of this document. appendix of this document.
skipping to change at page 3, line 15 skipping to change at page 4, line 4
A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 36 A.5. Evaluation Criteria - Security . . . . . . . . . . . . . . 36
A.5.1. Distribution and Validation of Persistent Public A.5.1. Distribution and Validation of Persistent Public
Keys and Certificates . . . . . . . . . . . . . . . . 36 Keys and Certificates . . . . . . . . . . . . . . . . 36
A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38 A.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 38
A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 40 A.5.3. Best Effort Encryption . . . . . . . . . . . . . . . . 40
A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 41 A.5.4. Upgrading Algorithms . . . . . . . . . . . . . . . . . 41
Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43 Appendix B. Out-of-Scope . . . . . . . . . . . . . . . . . . . . 43
B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 43 B.1. Shared Key Conferencing . . . . . . . . . . . . . . . . . 43
Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44 Appendix C. Requirement renumbering in -02 . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The work on media security started when the Session Initiation The work on media security started when the Session Initiation
Protocol (SIP) was still in its infancy. With the increased SIP Protocol (SIP) was still in its infancy. With the increased SIP
deployment and the availability of new SIP extensions and related deployment and the availability of new SIP extensions and related
protocols, the need for end-to-end security was re-evaluated. The protocols, the need for end-to-end security was re-evaluated. The
procedure of re-evaluating prior protocol work and design decisions procedure of re-evaluating prior protocol work and design decisions
is not an uncommon strategy and, to some extent, considered necessary is not an uncommon strategy and, to some extent, considered necessary
to ensure that the developed protocols indeed meet the previously to ensure that the developed protocols indeed meet the previously
skipping to change at page 5, line 37 skipping to change at page 5, line 37
and called user agents or, more commonly involves the SIP proxy and called user agents or, more commonly involves the SIP proxy
servers that were involved in the call setup. servers that were involved in the call setup.
media path: The media path is the route taken by media packets media path: The media path is the route taken by media packets
exchanged by the endpoints. In the simplest case, the endpoints exchanged by the endpoints. In the simplest case, the endpoints
exchange media directly, and the "media path" is defined by a exchange media directly, and the "media path" is defined by a
quartet of IP addresses and TCP/UDP ports, along with an IP route. quartet of IP addresses and TCP/UDP ports, along with an IP route.
In other cases, this path may include RTP relays, mixers, In other cases, this path may include RTP relays, mixers,
transcoders, session border controllers, NATs, or media gateways. transcoders, session border controllers, NATs, or media gateways.
Moreover, as this document discusses requirements for media security,
the nomenclature R-XXX is used to mark requrements, were XXX is the
requirement, which needs to be met.
3. Attack Scenarios 3. Attack Scenarios
The discussion in this section relates to requirements R-PASS-MEDIA, The discussion in this section relates to requirements R-PASS-MEDIA,
R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING. R-PASS-SIG, R-ASSOC, R-SIG-MEDIA, R-ACT-ACT, and R-ID-BINDING.
This document classifies adversaries according to their access and This document classifies adversaries according to their access and
their capabilities. An adversary might have access: their capabilities. An adversary might have access:
1. only to the media path, 1. only to the media path,
2. only to the signaling path, 2. only to the signaling path,
3. to the media path and to the signaling path. 3. to the media path and to the signaling path.
An attacker that can solely be located along the signaling path, and An attacker that can solely be located along the signaling path, and
does not have access to media (item 2), is not considered in this does not have access to media (item 2), is not considered in this
document. document.
There are two different types of adversaries, active and passive. An There are two different types of adversaries, active and passive. An
active adversary may need to be active with regard to the key active adversary may need to be active with regard to the key
skipping to change at page 9, line 46 skipping to change at page 9, line 51
| ^ | | ^ |
INVITE (2) | | | INVITE (4) INVITE (2) | | | INVITE (4)
& redirect (3) | | | & redirect (3) | | |
V | V V | V
++-++ ++----+ ++-++ ++----+
|Bob| |Carol| |Bob| |Carol|
+---+ +-----+ +---+ +-----+
Figure 1: Retargeting Figure 1: Retargeting
Using retargeting might lead to situations where the UAC does not Using retargeting might lead to situations where the User Agent
know where its request will be going. This might not immediately Client (UAC) does not know where its request will be going. This
seem like a serious problem; after all, when one places a telephone might not immediately seem like a serious problem; after all, when
call on the PSTN, one never really knows if it will be forwarded to a one places a telephone call on the PSTN, one never really knows if it
different number, who will pick up the line when it rings, and so on. will be forwarded to a different number, who will pick up the line
when it rings, and so on. However, when considering SIP mechanisms
However, when considering SIP mechanisms for authenticating the for authenticating the called party, this function can also make it
called party, this function can also make it difficult to difficult to differentiate an intermediary that is behaving
differentiate an intermediary that is behaving legitimately from an legitimately from an attacker. From this perspective, the main
attacker. From this perspective, the main problems with retargeting problems with retargeting are:
ares:
Not detectable by the caller: The originating user agent has no Not detectable by the caller: The originating user agent has no
means of anticipating that the condition will arise, nor any means means of anticipating that the condition will arise, nor any means
of determining that it has occurred until the call has already of determining that it has occurred until the call has already
been set up. been set up.
Not preventable by the caller: There is no existing mechanism that Not preventable by the caller: There is no existing mechanism that
might be employed by the originating user agent in order to might be employed by the originating user agent in order to
guarantee that the call will not be re-targeted. guarantee that the call will not be re-targeted.
skipping to change at page 16, line 27 skipping to change at page 16, line 27
use of RTP parameters (e.g., payload type or SSRC). use of RTP parameters (e.g., payload type or SSRC).
Media considerations: Media considerations:
R-AVOID-CLIPPING: R-AVOID-CLIPPING:
The media security key management protocol SHOULD avoid The media security key management protocol SHOULD avoid
clipping media before SDP answer without requiring Security clipping media before SDP answer without requiring Security
Preconditions [RFC5027]. This requirement comes from Preconditions [RFC5027]. This requirement comes from
Section 4.1. Section 4.1.
R-RTP-VALID: R-RTP-CHECK:
If SRTP key negotiation is performed over the media path (i.e., If SRTP key negotiation is performed over the media path (i.e.,
using the same UDP/TCP ports as media packets), the key using the same UDP/TCP ports as media packets), the key
negotiation packets MUST NOT pass the RTP validity check negotiation packets MUST NOT pass the RTP validity check
defined in Appendix A.1 of [RFC3550]. defined in Appendix A.1 of [RFC3550], so that SRTP negotiation
packets can be differentiated from RTP packets.
R-ASSOC: R-ASSOC:
The media security key management protocol SHOULD include a The media security key management protocol SHOULD include a
mechanism for associating key management messages with both the mechanism for associating key management messages with both the
signaling traffic that initiated the session and with protected signaling traffic that initiated the session and with protected
media traffic. It is useful to associate key management media traffic. It is useful to associate key management
messages with call signaling messages, as this allows the SDP messages with call signaling messages, as this allows the SDP
offerer to avoid performing CPU-consuming operations (e.g., offerer to avoid performing CPU-consuming operations (e.g.,
Diffie-Hellman or public key operations) with attackers that Diffie-Hellman or public key operations) with attackers that
have not seen the signaling messages. have not seen the signaling messages.
skipping to change at page 17, line 15 skipping to change at page 17, line 16
done by using the transport address indicated in the SDP, done by using the transport address indicated in the SDP,
although NATs can complicate this association. although NATs can complicate this association.
Note: due to RTP's design requirements, it is expected Note: due to RTP's design requirements, it is expected
that SRTP receivers will have to perform authentication that SRTP receivers will have to perform authentication
of any received SRTP packets. of any received SRTP packets.
R-NEGOTIATE: R-NEGOTIATE:
The media security key management protocol MUST allow a SIP The media security key management protocol MUST allow a SIP
User Agent to negotiate media security parameters for each User Agent to negotiate media security parameters for each
individual session. individual session. Such negotiation MUST NOT cause a two-time
pad (Section 9.1 of [RFC3711]).
R-PSTN: R-PSTN:
The media security key management protocol MUST support The media security key management protocol MUST support
termination of media security in a PSTN gateway. This termination of media security in a PSTN gateway. This
requirement is from Section 4.4. requirement is from Section 4.4.
5.2. Security Requirements 5.2. Security Requirements
This section describes overall security requirements and specific This section describes overall security requirements and specific
requirements from the attack scenarios (Section 3). requirements from the attack scenarios (Section 3).
skipping to change at page 17, line 45 skipping to change at page 17, line 47
offering additional SRTP cipher suites without incurring offering additional SRTP cipher suites without incurring
significant computational expense. significant computational expense.
R-CERTS: R-CERTS:
The key management protocol MUST NOT require that end-users The key management protocol MUST NOT require that end-users
obtain credentials (certificates or private keys) from a third- obtain credentials (certificates or private keys) from a third-
party trust anchor. party trust anchor.
R-FIPS: R-FIPS:
The media security key management protocol SHOULD use The media security key management protocol SHOULD use
algorithms that allow FIPS 140-2 [FIPS-140-2] certification. algorithms that allow FIPS 140-2 [FIPS-140-2] certification or
similar country-specific certification (e.g., [AISITSEC]).
The United States Government can only purchase and use crypto The United States Government can only purchase and use crypto
implementations that have been validated by the FIPS-140 implementations that have been validated by the FIPS-140
[FIPS-140-2] process: [FIPS-140-2] process:
"The FIPS-140 standard is applicable to all Federal "The FIPS-140 standard is applicable to all Federal
agencies that use cryptographic-based security systems to agencies that use cryptographic-based security systems to
protect sensitive information in computer and protect sensitive information in computer and
telecommunication systems, including voice systems. The telecommunication systems, including voice systems. The
adoption and use of this standard is available to private adoption and use of this standard is available to private
and commercial organizations." and commercial organizations."
Some commercial organizations, such as banks and defense Some commercial organizations, such as banks and defense
contractors, require or prefer equipment which has received the contractors, require or prefer equipment which has received the
same validation. same validation.
R-DOS: R-DOS:
The media security key management protocol SHOULD NOT introduce The media security key management protocol MUST NOT introduce
new denial of service vulnerabilities (e.g., the protocol any new significant denial of service vulnerabilities (e.g.,
should not request the endpoint to perform CPU-intensive the protocol should not request the endpoint to perform CPU-
operations without the client being able to validate or intensive operations without the client being able to validate
authorize the request). or authorize the request).
R-EXISTING: R-EXISTING:
The media security key management protocol SHOULD allow The media security key management protocol SHOULD allow
endpoints to authenticate using pre-existing cryptographic endpoints to authenticate using pre-existing cryptographic
credentials, e.g., certificates or pre-shared keys. credentials, e.g., certificates or pre-shared keys.
R-AGILITY: R-AGILITY:
The media security key management protocol MUST provide crypto- The media security key management protocol MUST provide crypto-
agility, i.e., the ability to adapt to evolving cryptography agility, i.e., the ability to adapt to evolving cryptography
and security requirements (update of cryptographic algorithms and security requirements (update of cryptographic algorithms
skipping to change at page 21, line 26 skipping to change at page 21, line 26
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[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)",
RFC 3711, March 2004. RFC 3711, March 2004.
[cryptval]
NIST, "Cryptographic Module Validation Program",
December 2006,
<http://csrc.nist.gov/cryptval/140-2APP.htm>.
9.2. Informative References 9.2. Informative References
[AISITSEC]
"Anwendungshinweise und Interpretationen (AIS) zu ITSEC",
January 2002,
<http://www.bsi.de/zertifiz/zert/interpr/aisitsec.htm>.
[H.248.1] ITU, "Gateway control protocol", June 2000, [H.248.1] ITU, "Gateway control protocol", June 2000,
<http://www.itu.int/rec/T-REC-H.248/e>. <http://www.itu.int/rec/T-REC-H.248/e>.
[I-D.baugher-mmusic-sdp-dh] [I-D.baugher-mmusic-sdp-dh]
Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges for
Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work Multimedia Sessions", draft-baugher-mmusic-sdp-dh-00 (work
in progress), February 2006. in progress), February 2006.
[I-D.dondeti-msec-rtpsec-mikeyv2] [I-D.dondeti-msec-rtpsec-mikeyv2]
Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY, Dondeti, L., "MIKEYv2: SRTP Key Management using MIKEY,
skipping to change at page 22, line 38 skipping to change at page 22, line 38
progress), July 2008. progress), July 2008.
[I-D.ietf-msec-mikey-ecc] [I-D.ietf-msec-mikey-ecc]
Milne, A., "ECC Algorithms for MIKEY", Milne, A., "ECC Algorithms for MIKEY",
draft-ietf-msec-mikey-ecc-03 (work in progress), draft-ietf-msec-mikey-ecc-03 (work in progress),
June 2007. June 2007.
[I-D.ietf-sip-certs] [I-D.ietf-sip-certs]
Jennings, C. and J. Fischl, "Certificate Management Jennings, C. and J. Fischl, "Certificate Management
Service for The Session Initiation Protocol (SIP)", Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-06 (work in progress), April 2008. draft-ietf-sip-certs-07 (work in progress), November 2008.
[I-D.ietf-tls-rfc4346-bis] [I-D.ietf-tls-rfc4346-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008. (work in progress), March 2008.
[I-D.jennings-sipping-multipart] [I-D.jennings-sipping-multipart]
Wing, D. and C. Jennings, "Session Initiation Protocol Wing, D. and C. Jennings, "Session Initiation Protocol
(SIP) Offer/Answer with Multipart Alternative", (SIP) Offer/Answer with Multipart Alternative",
draft-jennings-sipping-multipart-02 (work in progress), draft-jennings-sipping-multipart-02 (work in progress),
skipping to change at page 23, line 16 skipping to change at page 23, line 16
[I-D.stucker-sipping-early-media-coping] [I-D.stucker-sipping-early-media-coping]
Stucker, B., "Coping with Early Media in the Session Stucker, B., "Coping with Early Media in the Session
Initiation Protocol (SIP)", Initiation Protocol (SIP)",
draft-stucker-sipping-early-media-coping-03 (work in draft-stucker-sipping-early-media-coping-03 (work in
progress), October 2006. progress), October 2006.
[I-D.wing-sipping-srtp-key] [I-D.wing-sipping-srtp-key]
Wing, D., Audet, F., Fries, S., Tschofenig, H., and A. Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
Johnston, "Secure Media Recording and Transcoding with the Johnston, "Secure Media Recording and Transcoding with the
Session Initiation Protocol", Session Initiation Protocol",
draft-wing-sipping-srtp-key-03 (work in progress), draft-wing-sipping-srtp-key-04 (work in progress),
February 2008. October 2008.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-10 (work in progress), draft-zimmermann-avt-zrtp-11 (work in progress),
October 2008. November 2008.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
skipping to change at page 34, line 17 skipping to change at page 34, line 17
In SRTP, a cryptographic context is defined as the SSRC, destination In SRTP, a cryptographic context is defined as the SSRC, destination
network address, and destination transport port number. Whereas RTP, network address, and destination transport port number. Whereas RTP,
a flow is defined as the destination network address and destination a flow is defined as the destination network address and destination
transport port number. This results in a problem -- how to transport port number. This results in a problem -- how to
communicate the SSRC so that the SSRC can be used for the communicate the SSRC so that the SSRC can be used for the
cryptographic context. cryptographic context.
Two approaches have emerged for this communication. One, used by all Two approaches have emerged for this communication. One, used by all
MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
exchange. Another, used by Security Descriptions, is to apply "late exchange. Another, used by Security Descriptions, is to apply "late
bindng" -- that is, any new packet containing a previously-unseen binding" -- that is, any new packet containing a previously-unseen
SSRC (which arrives at the same destination network address and SSRC (which arrives at the same destination network address and
destination transport port number) will create a new cryptographic destination transport port number) will create a new cryptographic
context. Another approach, common amongst techniques with media-path context. Another approach, common amongst techniques with media-path
SRTP key establishment, is to require a handshake over that media SRTP key establishment, is to require a handshake over that media
path before SRTP packets are sent. MIKEY's approach changes RTP's path before SRTP packets are sent. MIKEY's approach changes RTP's
SSRC collision detection behavior by requiring RTP to pre-establish SSRC collision detection behavior by requiring RTP to pre-establish
the SSRC values for each session. the SSRC values for each session.
Another related issue is that SRTP introduces a rollover counter Another related issue is that SRTP introduces a rollover counter
(ROC), which records how many times the SRTP sequence number has (ROC), which records how many times the SRTP sequence number has
skipping to change at page 41, line 43 skipping to change at page 41, line 43
information which becomes computationally prohibitive. information which becomes computationally prohibitive.
Thus, it is important to keep the offerer's CPU impact fixed so that Thus, it is important to keep the offerer's CPU impact fixed so that
offering multiple new SRTP encryption and hash functions incurs no offering multiple new SRTP encryption and hash functions incurs no
additional expense. additional expense.
The following list describes the CPU effort involved in using each The following list describes the CPU effort involved in using each
key exchange technique. key exchange technique.
MIKEY-NULL MIKEY-NULL
No significant computaional expense. No significant computational expense.
MIKEY-PSK MIKEY-PSK
No significant computational expense. No significant computational expense.
MIKEY-RSA MIKEY-RSA
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
RSA operation to encrypt the TGK RSA operation to encrypt the TGK
MIKEY-RSA-R MIKEY-RSA-R
For each offered SRTP crypto suite, the offerer has to perform For each offered SRTP crypto suite, the offerer has to perform
skipping to change at page 45, line 24 skipping to change at page 45, line 24
R5 R-AVOID-CLIPPING R5 R-AVOID-CLIPPING
R6 R-PASS-MEDIA R6 R-PASS-MEDIA
R7 R-PASS-SIG R7 R-PASS-SIG
R8 R-PFS R8 R-PFS
R9 R-COMPUTE R9 R-COMPUTE
R10 R-RTP-VALID R10 R-RTP-CHECK
R11 (folded into R4; was reuse previous session) R11 (folded into R4; was reuse previous session)
R12 R-CERTS R12 R-CERTS
R13 R-FIPS R13 R-FIPS
R14 R-ASSOC R14 R-ASSOC
R15 R-ALLOW-RTP R15 R-ALLOW-RTP
skipping to change at page 48, line 4 skipping to change at line 2119
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Francois Audet Francois Audet
Nortel Nortel
4655 Great America Parkway 4655 Great America Parkway
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: audet@nortel.com Email: audet@nortel.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
This document was produced using xml2rfc v1.33 (of
http://xml.resource.org/) from a source in RFC-2629 XML format.
 End of changes. 23 change blocks. 
43 lines changed or deleted 57 lines changed or added

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