draft-ietf-avtcore-rtp-security-options-01.txt   draft-ietf-avtcore-rtp-security-options-02.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: April 25, 2013 University of Glasgow Expires: August 29, 2013 University of Glasgow
October 22, 2012 February 25, 2013
Options for Securing RTP Sessions Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-01 draft-ietf-avtcore-rtp-security-options-02
Abstract Abstract
The Real-time Transport Protocol (RTP) is used in a large number of The Real-time Transport Protocol (RTP) is used in a large number of
different application domains and environments. This hetrogeneity different application domains and environments. This heterogeneity
implies that different security mechanisms are needed to provide implies that different security mechanisms are needed to provide
services such as confidentiality, integrity and source authentication services such as confidentiality, integrity and source authentication
of RTP/RTCP packets suitable for the various environments. The range of RTP/RTCP packets suitable for the various environments. The range
of solutions makes it difficult for RTP-based application developers of solutions makes it difficult for RTP-based application developers
to pick the most suitable mechanism. This document provides an to pick the most suitable mechanism. This document provides an
overview of a number of security solutions for RTP, and gives overview of a number of security solutions for RTP, and gives
guidance for developers on how to choose the appropriate security guidance for developers on how to choose the appropriate security
mechanism. mechanism.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 33 skipping to change at page 5, line 33
management protocol becomes important in which security statements management protocol becomes important in which security statements
one can do. one can do.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Topology Figure 1: Point to Point Topology
2.2. Sessions Using an RTP Mixer 2.2. Sessions Using an RTP Mixer
An RTP mixer is a an RTP session level middlebox that one can build An RTP mixer is an RTP session level middlebox that one can build an
an multi-party RTP based conference around. The RTP mixer might multi-party RTP based conference around. The RTP mixer might
actually perform media mixing, like mixing audio or compositing video actually perform media mixing, like mixing audio or compositing video
images into a new media stream being sent from the mixer to a given images into a new media stream being sent from the mixer to a given
participant; or it might provide a conceptual stream, for example the participant; or it might provide a conceptual stream, for example the
video of the current active speaker. From a security point of view, video of the current active speaker. From a security point of view,
the important featurs of an RTP mixer is that it generates a new the important features of an RTP mixer is that it generates a new
media stream, and has its own source identifier, and does not simply media stream, and has its own source identifier, and does not simply
forward the original media. forward the original media.
An RTP session using a mixer might have a topology like that in An RTP session using a mixer might have a topology like that in
Figure 2. In this examples, participants A-D each send unicast RTP Figure 2. In this examples, participants A-D each send unicast RTP
traffic between themselves and the RTP mixer, and receive a RTP traffic between themselves and the RTP mixer, and receive a RTP
stream from the mixer, comprising a mixture of the streams from the stream from the mixer, comprising a mixture of the streams from the
other participants. other participants.
+---+ +------------+ +---+ +---+ +------------+ +---+
skipping to change at page 6, line 23 skipping to change at page 6, line 23
Figure 2: Example RTP Mixer topology Figure 2: Example RTP Mixer topology
A consequence of an RTP mixer having its own source identifier, and A consequence of an RTP mixer having its own source identifier, and
acting as an active participant towards the other end-points, is that acting as an active participant towards the other end-points, is that
the RTP mixer needs to be a trusted device that is part of the the RTP mixer needs to be a trusted device that is part of the
security context(s) established. The RTP mixer can also become a security context(s) established. The RTP mixer can also become a
security enforcing entity. For example, a common approach to secure security enforcing entity. For example, a common approach to secure
the topology in Figure 2 is to establish a security context between the topology in Figure 2 is to establish a security context between
the mixer and each participant independently, and have the mixer the mixer and each participant independently, and have the mixer
source authenticate each peer. The mixer then ensures that one source authenticate each peer. The mixer then ensures that one
participant cannot impersonsate another. participant cannot impersonate another.
2.3. Sessions Using an RTP Translator 2.3. Sessions Using an RTP Translator
RTP translators are middleboxes that provide various levels of in- RTP translators are middleboxes that provide various levels of in-
network media translation and transcoding. Their security properties network media translation and transcoding. Their security properties
vary widely, depending on which type of operations they attempt to vary widely, depending on which type of operations they attempt to
perform. We identify three different categories of RTP translator: perform. We identify three different categories of RTP translator:
transport translators, gateways, and media transcoders. We discuss transport translators, gateways, and media transcoders. We discuss
each in turn. each in turn.
2.3.1. Transport Translator (Relay) 2.3.1. Transport Translator (Relay)
A transport translator [RFC5117] operates on a level below RTP and A transport translator [RFC5117] operates on a level below RTP and
RTCP. It relays the RTP/RTCP traffic from one end-point to one or RTCP. It relays the RTP/RTCP traffic from one end-point to one or
more other addresses. This can be done based only on IP addresses more other addresses. This can be done based only on IP addresses
and transport protocol ports, with each receive port on the and transport protocol ports, with each receive port on the
translator can have a very basic list of where to forward traffic. translator can have a very basic list of where to forward traffic.
Transport translators should also implement ingress filtering to Transport translators also need to implement ingress filtering to
prevent random traffic from being forwarded that isn't coming from a prevent random traffic from being forwarded that isn't coming from a
participant in the conference. participant in the conference.
Figure 3 shows an example transport translator, where traffic from Figure 3 shows an example transport translator, where traffic from
any one of the four participants will be forwarded to the other three any one of the four participants will be forwarded to the other three
participants unchanged. The resulting topology is very similar to participants unchanged. The resulting topology is very similar to
Any source Multicast (ASM) session (as discussed in Section 2.4), but Any source Multicast (ASM) session (as discussed in Section 2.4), but
implemented at the application layer. implemented at the application layer.
+---+ +------------+ +---+ +---+ +------------+ +---+
skipping to change at page 10, line 13 skipping to change at page 10, line 13
security mechanisms that can be used with RTP. security mechanisms that can be used with RTP.
3.1. Secure RTP 3.1. Secure RTP
The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly
used mechanisms to provide confidentiality, integrity protection and used mechanisms to provide confidentiality, integrity protection and
source authentication for RTP. SRTP was developed with RTP header source authentication for RTP. SRTP was developed with RTP header
compression and third party monitors in mind. Thus the RTP header is compression and third party monitors in mind. Thus the RTP header is
not encrypted in RTP data packets, and the first 8 bytes of the first not encrypted in RTP data packets, and the first 8 bytes of the first
RTCP packet header in each compound RTCP packet are not encrypted. RTCP packet header in each compound RTCP packet are not encrypted.
The entirity of RTP packets and compound RTCP packets are integrity The entirety of RTP packets and compound RTCP packets are integrity
protected. This allows RTP header compression to work, and lets protected. This allows RTP header compression to work, and lets
third party monitors determine what RTP traffic flows exist based on third party monitors determine what RTP traffic flows exist based on
the SSRC fields, but protects the sensitive content. the SSRC fields, but protects the sensitive content.
The source authentication guarantees provided by SRTP are highly The source authentication guarantees provided by SRTP are highly
dependent on the cryptographic transform and key-management scheme dependent on the cryptographic transform and key-management scheme
used. In some cases all a receiver can determine is whether the used. In some cases all a receiver can determine is whether the
packets come from someone in the group security context, and not what packets come from someone in the group security context, and not what
group member send the packets. Thus, the source authentication group member send the packets. Thus, the source authentication
guarantees depend also on the session topology. Some cryptographic guarantees depend also on the session topology. Some cryptographic
skipping to change at page 11, line 52 skipping to change at page 11, line 52
A Datagram Transport Layer Security extension exists for establishing A Datagram Transport Layer Security extension exists for establishing
SRTP keys [RFC5763][RFC5764]. This extension provides secure key- SRTP keys [RFC5763][RFC5764]. This extension provides secure key-
exchange between two peers, including perfect forward secrecy and exchange between two peers, including perfect forward secrecy and
enabling binding strong identity verification to an end-point. The enabling binding strong identity verification to an end-point. The
default key generation will generate a key that contains material default key generation will generate a key that contains material
contributed by both peers. The key-exchange happens in the media contributed by both peers. The key-exchange happens in the media
plane directly between the peers. The common key-exchange procedures plane directly between the peers. The common key-exchange procedures
will take two round trips assuming no losses. TLS resumption can be will take two round trips assuming no losses. TLS resumption can be
used when establishing additional media streams with the same peer, used when establishing additional media streams with the same peer,
used reducing the setup time to one RTT. used reducing the set-up time to one RTT.
DTLS-SRTP key management can use the signalling protocol in three DTLS-SRTP key management can use the signalling protocol in three
ways. First, to agree on using DTLS-SRTP for media security. ways. First, to agree on using DTLS-SRTP for media security.
Secondly, to determine the network location (address and port) where Secondly, to determine the network location (address and port) where
each side is running an DTLS listener to let the parts perform the each side is running an DTLS listener to let the parts perform the
key-management handshakes that generate the keys used by SRTP. key-management handshakes that generate the keys used by SRTP.
Finally, to exchange hashes of each sides certificates to enable each Finally, to exchange hashes of each sides certificates to enable each
side to verify that they have connected to the by signalling side to verify that they have connected to the by signalling
indicated port and not a man in the middle. That way enabling some indicated port and not a man in the middle. That way enabling some
binding between the key-exchange and the signalling. This usage is binding between the key-exchange and the signalling. This usage is
skipping to change at page 13, line 29 skipping to change at page 13, line 29
management service and tickets, like Kerberos. management service and tickets, like Kerberos.
IBAKE: [RFC6267] uses a key management services (KMS) but with lower IBAKE: [RFC6267] uses a key management services (KMS) but with lower
demand on the KMS. If provides both perfect forward and backwards demand on the KMS. If provides both perfect forward and backwards
secrecy. secrecy.
SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY.
Based on Identity based Public Key Cryptography to establish a Based on Identity based Public Key Cryptography to establish a
shared secret value and certificate less signatures to provide shared secret value and certificate less signatures to provide
source authentication. It features include simplex transmission, source authentication. It features include simplex transmission,
scalability, low-latency call setup, and support for secure scalability, low-latency call set-up, and support for secure
deferred delivery. deferred delivery.
MIKEY messages has several different defined transports. [RFC4567] MIKEY messages has several different defined transports. [RFC4567]
defines how MIKEY messages can be embedded in general SDP for usage defines how MIKEY messages can be embedded in general SDP for usage
with the signalling protocols SIP, SAP and RTSP. There also exist an with the signalling protocols SIP, SAP and RTSP. There also exist an
3GPP defined usage of MIKEY that sends MIKEY messages directly over 3GPP defined usage of MIKEY that sends MIKEY messages directly over
UDP to key the receivers of Multimedia Broadcast and Multicast UDP to key the receivers of Multimedia Broadcast and Multicast
Service (MBMS) [3GPP.33.246]. Service (MBMS) [3GPP.33.246].
Based on the many choices it is important to consider the properties Based on the many choices it is important to consider the properties
skipping to change at page 13, line 51 skipping to change at page 13, line 51
are candidates for ones usage. More information on the applicability are candidates for ones usage. More information on the applicability
of the different MIKEY modes can be found in [RFC5197]. of the different MIKEY modes can be found in [RFC5197].
3.1.3. Key Management for SRTP: Security Descriptions 3.1.3. Key Management for SRTP: Security Descriptions
[RFC4568] provides a keying solution based on sending plain text keys [RFC4568] provides a keying solution based on sending plain text keys
in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/ in SDP [RFC4566]. It is primarily used with SIP and SDP Offer/
Answer, and is well-defined in point to point sessions where each Answer, and is well-defined in point to point sessions where each
side declares its own unique key. Using Security Descriptions to side declares its own unique key. Using Security Descriptions to
establish group keys is less well defined, and can have security establish group keys is less well defined, and can have security
issues as the SSRC uniqurness property can't be guaranteed. issues as the SSRC uniqueness property can't be guaranteed.
Since keys are transported in plain text in SDP, they can easily be Since keys are transported in plain text in SDP, they can easily be
intercepted unless the SDP carrying protocol provides strong end-to- intercepted unless the SDP carrying protocol provides strong end-to-
end confidentiality and authentication guarantees. This is not the end confidentiality and authentication guarantees. This is not the
common use of security descriptions with SIP, where instead hop by common use of security descriptions with SIP, where instead hop by
hop security is provided between signalling nodes using TLS. This hop security is provided between signalling nodes using TLS. This
still leaves the keying material sensitive to capture by the still leaves the keying material sensitive to capture by the
traversed signalling nodes. Thus in most cases the security traversed signalling nodes. Thus in most cases the security
properties of security description are weak. properties of security description are weak.
skipping to change at page 18, line 48 skipping to change at page 18, line 48
algorithm is used, and the length of the integrity tags. However algorithm is used, and the length of the integrity tags. However
equally, important is to consider who is providing the integrity equally, important is to consider who is providing the integrity
assertion, what is the source of the integrity tag, and what are the assertion, what is the source of the integrity tag, and what are the
risks of modifications happening prior to that point where protection risks of modifications happening prior to that point where protection
is applied? RTP applications that rely on central nodes need to is applied? RTP applications that rely on central nodes need to
consider if hop-by-hop integrity is acceptable, or if true end-to-end consider if hop-by-hop integrity is acceptable, or if true end-to-end
integrity protection is needed? Is it important to be able to tell integrity protection is needed? Is it important to be able to tell
if a middlebox has modified the data? There are some uses of RTP if a middlebox has modified the data? There are some uses of RTP
that require trusted middleboxes that can modify the data in a way that require trusted middleboxes that can modify the data in a way
that doesn't break integrity protection as seen by the receiver, for that doesn't break integrity protection as seen by the receiver, for
example local advertisment insertion in IPTV systems; there are also example local advertisement insertion in IPTV systems; there are also
uses where it is essential that such in-network modification be uses where it is essential that such in-network modification be
detectable. RTP can support both, with appropriate choices of detectable. RTP can support both, with appropriate choices of
security mechanisms. security mechanisms.
Integrity of the data is commonly closely tied to the question of Integrity of the data is commonly closely tied to the question of
source authentication. That is, it becomes important to know who source authentication. That is, it becomes important to know who
makes an integrity assertion for the data. makes an integrity assertion for the data.
4.1.3. Source Authentication 4.1.3. Source Authentication
skipping to change at page 20, line 8 skipping to change at page 20, line 8
nodes involved. nodes involved.
For example, consider a point to point communication system that For example, consider a point to point communication system that
use DTLS-SRTP using self-signed certificates for key-management, use DTLS-SRTP using self-signed certificates for key-management,
and SIP for signalling. In such a system the end-points for the and SIP for signalling. In such a system the end-points for the
DTLS-SRTP handshake have securely established keys that are not DTLS-SRTP handshake have securely established keys that are not
visible to the signalling nodes. However, as the certificates visible to the signalling nodes. However, as the certificates
used by DTLS is not bound to any PKI they can't be verified. used by DTLS is not bound to any PKI they can't be verified.
Instead, hashes over the certificate are sent over the signalling Instead, hashes over the certificate are sent over the signalling
path. If the signalling can be trusted not to collaborate on path. If the signalling can be trusted not to collaborate on
performaning a man in the middle attack by modifying the hashes, performing a man in the middle attack by modifying the hashes,
then the end-points can verify that they have reached the peer then the end-points can verify that they have reached the peer
they are doing signalling with. they are doing signalling with.
Using Identities: If the applications have access to a system that Using Identities: If the applications have access to a system that
can provide verifiable identities, then the source authentication can provide verifiable identities, then the source authentication
can be bound to that identity. For example, in a point-to-point can be bound to that identity. For example, in a point-to-point
communication even symmetric key crypto, where the key-management communication even symmetric key crypto, where the key-management
can assert that the key has only been exchanged with a particular can assert that the key has only been exchanged with a particular
identity, can provide a strong assertion about who is sending the identity, can provide a strong assertion about who is sending the
traffic. traffic.
Note that all levels of the system much have matching capability Note that all levels of the system much have matching capability
to assert identity. Having the signalling assert that you include to assert identity. Having the signalling assert that you include
a particular identity in a multi-party communication session where a particular identity in a multi-party communication session where
the key-management systems establish keys in a way that one can the key-management systems establish keys in a way that one can
assert that only the given identity has gotten the key. Using a assert that only the given identity has gotten the key. Using a
authentication mechanism build on a group key and otherwise can't authentication mechanism build on a group key and otherwise can't
provide any assertion who sent the traffic than anyone that got provide any assertion who sent the traffic than anyone that got
the key provides no strong assertability on the media level than: the key provides no strong assertion on the media level than:
Someone that has gotten the security context (key) sent this Someone that has gotten the security context (key) sent this
traffic. traffic.
4.1.4. Identity 4.1.4. Identity
As seen in the previous section, having an identity provider system As seen in the previous section, having an identity provider system
can benefit the applications by enabling them to do strong assertion can benefit the applications by enabling them to do strong assertion
between identity and the actual media source. Therefore, the need between identity and the actual media source. Therefore, the need
for identity needs to be considered. However, having identity for identity needs to be considered. However, having identity
systems might not be suitable for all types of application, since systems might not be suitable for all types of application, since
skipping to change at page 24, line 36 skipping to change at page 24, line 36
9. Informative References 9. Informative References
[3GPP.23.234] [3GPP.23.234]
3GPP, "Technical Specification Group Services and System 3GPP, "Technical Specification Group Services and System
Aspects; Transparent end-to-end Packet-switched Streaming Aspects; Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234 Service (PSS); Protocols and codecs", 3GPP TS 26.234
8.4.0, September 2009. 8.4.0, September 2009.
[3GPP.33.246] [3GPP.33.246]
3GPP, "3G Security; Security of Multimedia Broadcast/ 3GPP, "3G Security; Security of Multimedia Broadcast/
Multicast Service (MBMS)", 3GPP TS 33.246 10.0.0, Multicast Service (MBMS)", 3GPP TS 33.246 10.1.0,
December 2010. December 2012.
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Single Security Mechanism", Framework: Why RTP Does Not Mandate a Single Media
draft-ietf-avt-srtp-not-mandatory-10 (work in progress), Security Solution", draft-ietf-avt-srtp-not-mandatory-11
July 2012. (work in progress), November 2012.
[I-D.ietf-avtcore-aria-srtp] [I-D.ietf-avtcore-aria-srtp]
Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The
ARIA Algorithm and Its Use with the Secure Real-time ARIA Algorithm and Its Use with the Secure Real-time
Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-00 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-01
(work in progress), May 2012. (work in progress), December 2012.
[I-D.ietf-avtcore-srtp-aes-gcm] [I-D.ietf-avtcore-srtp-aes-gcm]
McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
Encryption in Secure RTP (SRTP)", Encryption in Secure RTP (SRTP)",
draft-ietf-avtcore-srtp-aes-gcm-03 (work in progress), draft-ietf-avtcore-srtp-aes-gcm-05 (work in progress),
September 2012. February 2013.
[I-D.ietf-avtcore-srtp-ekt] [I-D.ietf-avtcore-srtp-ekt]
McGrew, D., Wing, D., and K. Fischer, "Encrypted Key McGrew, D., Wing, D., and K. Fischer, "Encrypted Key
Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-avtcore-srtp-encrypted-header-ext] [I-D.ietf-avtcore-srtp-encrypted-header-ext]
Lennox, J., "Encryption of Header Extensions in the Secure Lennox, J., "Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", Real-Time Transport Protocol (SRTP)",
draft-ietf-avtcore-srtp-encrypted-header-ext-02 (work in draft-ietf-avtcore-srtp-encrypted-header-ext-05 (work in
progress), July 2012. progress), February 2013.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-04 (work based Applications", draft-ietf-rtcweb-overview-06 (work
in progress), June 2012. in progress), February 2013.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture",
draft-ietf-rtcweb-security-arch-03 (work in progress), draft-ietf-rtcweb-security-arch-06 (work in progress),
July 2012. January 2013.
[I-D.rescorla-avtcore-random-cname] [I-D.rescorla-avtcore-random-cname]
Rescorla, E., "Random algorithm for RTP CNAME generation", Rescorla, E., "Random algorithm for RTP CNAME generation",
draft-rescorla-avtcore-random-cname-00 (work in progress), draft-rescorla-avtcore-random-cname-00 (work in progress),
July 2012. July 2012.
[I-D.rescorla-rtcweb-generic-idp] [I-D.rescorla-rtcweb-generic-idp]
Rescorla, E., "RTCWEB Generic Identity Provider Rescorla, E., "RTCWEB Generic Identity Provider
Interface", draft-rescorla-rtcweb-generic-idp-01 (work in Interface", draft-rescorla-rtcweb-generic-idp-01 (work in
progress), March 2012. progress), March 2012.
 End of changes. 23 change blocks. 
34 lines changed or deleted 34 lines changed or added

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