draft-ietf-rtcweb-security-arch-00.txt   draft-ietf-rtcweb-security-arch-01.txt 
RTCWEB E. Rescorla RTCWEB E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Standards Track January 22, 2012 Intended status: Standards Track March 12, 2012
Expires: July 25, 2012 Expires: September 13, 2012
RTCWEB Security Architecture RTCWEB Security Architecture
draft-ietf-rtcweb-security-arch-00 draft-ietf-rtcweb-security-arch-01
Abstract Abstract
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers. The major use cases for RTCWEB technology are between Web browsers. The major use cases for RTCWEB technology are
real-time audio and/or video calls, Web conferencing, and direct data real-time audio and/or video calls, Web conferencing, and direct data
transfer. Unlike most conventional real-time systems (e.g., SIP- transfer. Unlike most conventional real-time systems (e.g., SIP-
based soft phones) RTCWEB communications are directly controlled by based soft phones) RTCWEB communications are directly controlled by
some Web server, which poses new security challenges. For instance, some Web server, which poses new security challenges. For instance,
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 July 25, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 10 5.1. Origin and Web Security Issues . . . . . . . . . . . . . . 10
5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 11 5.2. Device Permissions Model . . . . . . . . . . . . . . . . . 11
5.3. Communications Consent . . . . . . . . . . . . . . . . . . 12 5.3. Communications Consent . . . . . . . . . . . . . . . . . . 12
5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 13 5.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 13
5.5. Communications Security . . . . . . . . . . . . . . . . . 13 5.5. Communications Security . . . . . . . . . . . . . . . . . 13
5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 15 5.6. Web-Based Peer Authentication . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Communications Security . . . . . . . . . . . . . . . . . 16 6.1. Communications Security . . . . . . . . . . . . . . . . . 16
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Real-Time Communications on the Web (RTCWEB) working group is The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications tasked with standardizing protocols for real-time communications
between Web browsers. The major use cases for RTCWEB technology are between Web browsers. The major use cases for RTCWEB technology are
real-time audio and/or video calls, Web conferencing, and direct data real-time audio and/or video calls, Web conferencing, and direct data
transfer. Unlike most conventional real-time systems, (e.g., SIP- transfer. Unlike most conventional real-time systems, (e.g., SIP-
based[RFC3261] soft phones) RTCWEB communications are directly based[RFC3261] soft phones) RTCWEB communications are directly
skipping to change at page 8, line 24 skipping to change at page 8, line 24
microphone. In this case, because Alice is a long-term user of the microphone. In this case, because Alice is a long-term user of the
calling service, she has made a permissions grant (i.e., a setting in calling service, she has made a permissions grant (i.e., a setting in
the browser) to allow the calling service to access her camera and the browser) to allow the calling service to access her camera and
microphone any time it wants. The browser checks this setting when microphone any time it wants. The browser checks this setting when
the camera and microphone requests are made and thus allows them. the camera and microphone requests are made and thus allows them.
In the current W3C API, once some streams have been added, Alice's In the current W3C API, once some streams have been added, Alice's
browser + JS generates a signaling message The format of this data is browser + JS generates a signaling message The format of this data is
currently undefined. It may be a complete message as defined by ROAP currently undefined. It may be a complete message as defined by ROAP
[I-D.jennings-rtcweb-signaling] or separate media description and [I-D.jennings-rtcweb-signaling] or separate media description and
transport messages as defined in JSEP [REF] or may be assembled transport messages as defined in [I-D.ietf-rtcweb-jsep] or may be
piecemeal by the JS. In either case, it will contain: assembled piecemeal by the JS. In either case, it will contain:
o Media channel information o Media channel information
o ICE candidates o ICE candidates
o A fingerprint attribute binding the communication to Alice's o A fingerprint attribute binding the communication to Alice's
public key [RFC5763] public key [RFC5763]
[Note that the above implies that this information should appear in [Note that it is currently unclear where JSEP will eventually put
JSEP's transport-level messages.] Prior to sending out the signaling this information, in the SDP or in the transport info.] Prior to
message, the PeerConnection code contacts the identity service and sending out the signaling message, the PeerConnection code contacts
obtains an assertion binding Alice's identity to her fingerprint. the identity service and obtains an assertion binding Alice's
The exact details depend on the identity service (though as discussed identity to her fingerprint. The exact details depend on the
in [I-D.rescorla-rtcweb-generic-idp] PeerConnection can be agnostic identity service (though as discussed in
to them), but for now it's easiest to think of as a BrowserID [I-D.rescorla-rtcweb-generic-idp] PeerConnection can be agnostic to
assertion. The assertion may bind other information to the identity them), but for now it's easiest to think of as a BrowserID assertion.
besides the fingerprint, but at minimum it needs to bind the The assertion may bind other information to the identity besides the
fingerprint. fingerprint, but at minimum it needs to bind the fingerprint.
This message is sent to the signaling server, e.g., by XMLHttpRequest This message is sent to the signaling server, e.g., by XMLHttpRequest
[XmlHttpRequest] or by WebSockets [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
[I-D.ietf-hybi-thewebsocketprotocol]. The signaling server processes processes the message from Alice's browser, determines that this is a
the message from Alice's browser, determines that this is a call to call to Bob and sends a signaling message to Bob's browser (again,
Bob and sends a signaling message to Bob's browser (again, the format the format is currently undefined). The JS on Bob's browser
is currently undefined). The JS on Bob's browser processes it, and processes it, and alerts Bob to the incoming call and to Alice's
alerts Bob to the incoming call and to Alice's identity. In this identity. In this case, Alice has provided an identity assertion and
case, Alice has provided an identity assertion and so Bob's browser so Bob's browser contacts Alice's identity provider (again, this is
contacts Alice's identity provider (again, this is done in a generic done in a generic way so the browser has no specific knowledge of the
way so the browser has no specific knowledge of the IdP) to verity IdP) to verity the assertion. This allows the browser to display a
the assertion. This allows the browser to display a trusted element trusted element indicating that a call is coming in from Alice. If
indicating that a call is coming in from Alice. If Alice is in Bob's Alice is in Bob's address book, then this interface might also
address book, then this interface might also include her real name, a include her real name, a picture, etc. The calling site will also
picture, etc. The calling site will also provide some user interface provide some user interface element (e.g., a button) to allow Bob to
element (e.g., a button) to allow Bob to answer the call, though this answer the call, though this is most likely not part of the trusted
is most likely not part of the trusted UI. UI.
If Bob agrees [I am ignoring early media for now], a PeerConnection If Bob agrees [I am ignoring early media for now], a PeerConnection
is instantiated with the message from Alice's side. Then, a similar is instantiated with the message from Alice's side. Then, a similar
process occurs as on Alice's browser: Bob's browser verifies that process occurs as on Alice's browser: Bob's browser verifies that
the calling service is approved, the media streams are created, and a the calling service is approved, the media streams are created, and a
return signaling message containing media information, ICE return signaling message containing media information, ICE
candidates, and a fingerprint is sent back to Alice via the signaling candidates, and a fingerprint is sent back to Alice via the signaling
service. If Bob has a relationship with an IdP, the message will service. If Bob has a relationship with an IdP, the message will
also come with an identity assertion. also come with an identity assertion.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
Once the ICE checks have completed [more specifically, once some ICE Once the ICE checks have completed [more specifically, once some ICE
checks have completed], Alice and Bob can set up a secure channel. checks have completed], Alice and Bob can set up a secure channel.
This is performed via DTLS [RFC4347] (for the data channel) and DTLS- This is performed via DTLS [RFC4347] (for the data channel) and DTLS-
SRTP [RFC5763] for the media channel. Specifically, Alice and Bob SRTP [RFC5763] for the media channel. Specifically, Alice and Bob
perform a DTLS handshake on every channel which has been established perform a DTLS handshake on every channel which has been established
by ICE. The total number of channels depends on the amount of by ICE. The total number of channels depends on the amount of
muxing; in the most likely case we are using both RTP/RTCP mux and muxing; in the most likely case we are using both RTP/RTCP mux and
muxing multiple media streams on the same channel, in which case muxing multiple media streams on the same channel, in which case
there is only one DTLS handshake. Once the DTLS handshake has there is only one DTLS handshake. Once the DTLS handshake has
completed, the keys are extracted and used to key SRTP for the media completed, the keys are exported [RFC5705] and used to key SRTP for
channels. the media channels.
At this point, Alice and Bob know that they share a set of secure At this point, Alice and Bob know that they share a set of secure
data and/or media channels with keys which are not known to any data and/or media channels with keys which are not known to any
third-party attacker. If Alice and Bob authenticated via their IdPs, third-party attacker. If Alice and Bob authenticated via their IdPs,
then they also know that the signaling service is not attacking them. then they also know that the signaling service is not attacking them.
Even if they do not use an IdP, as long as they have minimal trust in Even if they do not use an IdP, as long as they have minimal trust in
the signaling service not to perform a man-in-the-middle attack, they the signaling service not to perform a man-in-the-middle attack, they
know that their communications are secure against the signaling know that their communications are secure against the signaling
service as well. service as well.
skipping to change at page 10, line 48 skipping to change at page 10, line 48
to receive her communications. ICE specifies periodic STUN to receive her communications. ICE specifies periodic STUN
keepalizes but only if media is not flowing. Because the consent keepalizes but only if media is not flowing. Because the consent
issue is more difficult here, we require RTCWeb implementations to issue is more difficult here, we require RTCWeb implementations to
periodically send keepalives. If a keepalive fails and no new ICE periodically send keepalives. If a keepalive fails and no new ICE
channels can be established, then the session is terminated. channels can be established, then the session is terminated.
5. Detailed Technical Description 5. Detailed Technical Description
5.1. Origin and Web Security Issues 5.1. Origin and Web Security Issues
The basic unit of permissions for RTCWEB is the origin The basic unit of permissions for RTCWEB is the origin [RFC6454].
[I-D.abarth-origin]. Because the security of the origin depends on Because the security of the origin depends on being able to
being able to authenticate content from that origin, the origin can authenticate content from that origin, the origin can only be
only be securely established if data is transferred over HTTPS securely established if data is transferred over HTTPS [RFC2818].
[RFC2818]. Thus, clients MUST treat HTTP and HTTPS origins as Thus, clients MUST treat HTTP and HTTPS origins as different
different permissions domains and SHOULD NOT permit access to any permissions domains. [Note: this follows directly from the origin
RTCWEB functionality from scripts fetched over non-secure (HTTP) security model and is stated here merely for clarity.]
origins. If an HTTPS origin contains mixed active content
(regardless of whether it is present on the specific page attempting Many web browsers currently forbid by default any active mixed
to access RTCWEB functionality), any access MUST be treated as if it content on HTTPS pages. I.e., when JS is loaded from an HTTP origin
came from the HTTP origin. For instance, if a onto an HTTPS page, an error is displayed and the content is not
https://www.example.com/example.html loads executed unless the user overrides the error. Any browser which
https://www.example.com/example.js and enforces such a policy will also not permit access to RTCWEB
http://www.example.org/jquery.js, any attempt by example.js to access functionality from mixed content pages. It is RECOMMENDED that
RTCWeb functionality MUST be treated as if it came from browsers which allow active mixed content nevertheless disable RTCWEB
http://www.example.com/. Note that many browsers already track mixed functionality in mixed content settings. [[ OPEN ISSUE: Should this
content and either forbid it by default or display a warning. [[ OPEN be a 2119 MUST? It's not clear what set of conditions would make
ISSUE: This seems to be wrong, but I'm not sure what's right yet. ]] this OK, other than that browser manufacturers have traditionally
been permissive here here.]] Note that it is possible for a page
which was not mixed content to become mixed content during the
duration of the call. Implementations MAY choose to terminate the
call or display a warning at that point, but it is also permissible
to ignore this condition. This is a deliberate implementation
complexity versus security tradeoff.
5.2. Device Permissions Model 5.2. Device Permissions Model
Implementations MUST obtain explicit user consent prior to providing Implementations MUST obtain explicit user consent prior to providing
access to the camera and/or microphone. Implementations MUST at access to the camera and/or microphone. Implementations MUST at
minimum support the following two permissions models: minimum support the following two permissions models:
o Requests for one-time camera/microphone access. o Requests for one-time camera/microphone access.
o Requests for permanent access. o Requests for permanent access.
skipping to change at page 13, line 8 skipping to change at page 13, line 14
document takes no position on the split between ICE in JS and ICE in document takes no position on the split between ICE in JS and ICE in
the browser. The above text is written the way it is for editorial the browser. The above text is written the way it is for editorial
convenience and will be modified appropriately if the WG decides on convenience and will be modified appropriately if the WG decides on
ICE in the JS.] ICE in the JS.]
Implementations MUST send keepalives no less frequently than every 30 Implementations MUST send keepalives no less frequently than every 30
seconds regardless of whether traffic is flowing or not. If a seconds regardless of whether traffic is flowing or not. If a
keepalive fails then the implementation MUST either attempt to find a keepalive fails then the implementation MUST either attempt to find a
new valid path via ICE or terminate media for that ICE component. new valid path via ICE or terminate media for that ICE component.
Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding Note that ICE [RFC5245]; Section 10 keepalives use STUN Binding
Indications which are one-way and therefore not sufficient. We will Indications which are one-way and therefore not sufficient. Instead,
need to define a new mechanism for this. [PROPOSED SOLUTION: the consent freshness mechanism [I-D.muthu-behave-consent-freshness]
Replace STUN Binding Indications with STUN Binding Requests and MUST be used.
require that a failed transaction causes the results above.]
5.4. IP Location Privacy 5.4. IP Location Privacy
A side effect of the default ICE behavior is that the peer learns A side effect of the default ICE behavior is that the peer learns
one's IP address, which leaks large amounts of location information, one's IP address, which leaks large amounts of location information,
especially for mobile devices. This has negative privacy especially for mobile devices. This has negative privacy
consequences in some circumstances. The following two API consequences in some circumstances. The following two API
requirements are intended to mitigate this issue: requirements are intended to mitigate this issue:
API Requirement: The API MUST provide a mechanism to suppress ICE API Requirement: The API MUST provide a mechanism to suppress ICE
skipping to change at page 13, line 41 skipping to change at page 13, line 46
This prevents the peer from learning one's IP address at all. The This prevents the peer from learning one's IP address at all. The
API MUST provide a mechanism for the calling application to API MUST provide a mechanism for the calling application to
reconfigure an existing call to add non-TURN candidates. Taken reconfigure an existing call to add non-TURN candidates. Taken
together, these requirements allow ICE negotiation to start together, these requirements allow ICE negotiation to start
immediately on incoming call notification, thus reducing post-dial immediately on incoming call notification, thus reducing post-dial
delay, but also to avoid disclosing the user's IP address until delay, but also to avoid disclosing the user's IP address until
they have decided to answer. they have decided to answer.
5.5. Communications Security 5.5. Communications Security
Implementations MUST implement DTLS and DTLS-SRTP. All data channels Implementations MUST implement DTLS [RFC4347] and DTLS-SRTP
MUST be secured via DTLS. DTLS-SRTP MUST be offered for every media [RFC5763][RFC5764]. All data channels MUST be secured via DTLS.
channel and MUST be the default; i.e., if an implementation receives DTLS-SRTP MUST be offered for every media channel and MUST be the
an offer for DTLS-SRTP and SDES and/or plain RTP, DTLS-SRTP MUST be default; i.e., if an implementation receives an offer for DTLS-SRTP
selected. and SDES and/or plain RTP, DTLS-SRTP MUST be selected.
[OPEN ISSUE: What should the settings be here? MUST?] [OPEN ISSUE: What should the settings be here? MUST?]
Implementations MAY support SDES and RTP for media traffic for Implementations MAY support SDES and RTP for media traffic for
backward compatibility purposes. backward compatibility purposes.
API Requirement: The API MUST provide a mechanism to indicate that a API Requirement: The API MUST provide a mechanism to indicate that a
fresh DTLS key pair is to be generated for a specific call. This fresh DTLS key pair is to be generated for a specific call. This
is intended to allow for unlinkability. Note that there are also is intended to allow for unlinkability. Note that there are also
settings where it is attractive to use the same keying material settings where it is attractive to use the same keying material
repeatedly, especially those with key continuity-based repeatedly, especially those with key continuity-based
skipping to change at page 17, line 7 skipping to change at page 17, line 10
However, these privacy protections come at a performance cost in However, these privacy protections come at a performance cost in
terms of using TURN relays and, in the latter case, delaying ICE. terms of using TURN relays and, in the latter case, delaying ICE.
Sites SHOULD make users aware of these tradeoffs. Sites SHOULD make users aware of these tradeoffs.
Note that the protections provided here assume a non-malicious Note that the protections provided here assume a non-malicious
calling service. As the calling service always knows the users calling service. As the calling service always knows the users
status and (absent the use of a technology like Tor) their IP status and (absent the use of a technology like Tor) their IP
address, they can violate the users privacy at will. Users who wish address, they can violate the users privacy at will. Users who wish
privacy against the calling sites they are using must use separate privacy against the calling sites they are using must use separate
privacy enhancing technologies such as Tor. privacy enhancing technologies such as Tor. Combined RTCWEB/Tor
implementations SHOULD arrange to route the media as well as the
signaling through Tor. [Currently this will produce very suboptimal
performance.]
6.3. Denial of Service 6.3. Denial of Service
The consent mechanisms described in this document are intended to The consent mechanisms described in this document are intended to
mitigate denial of service attacks in which an attacker uses clients mitigate denial of service attacks in which an attacker uses clients
to send large amounts of traffic to a victim without the consent of to send large amounts of traffic to a victim without the consent of
the victim. While these mechanisms are sufficient to protect victims the victim. While these mechanisms are sufficient to protect victims
who have not implemented RTCWEB at all, RTCWEB implementations need who have not implemented RTCWEB at all, RTCWEB implementations need
to be more careful. to be more careful.
skipping to change at page 17, line 40 skipping to change at page 17, line 46
(which the attacker cannot control). (which the attacker cannot control).
Another related attack is for the signaling service to swap the ICE Another related attack is for the signaling service to swap the ICE
candidates for the audio and video streams, thus forcing a browser to candidates for the audio and video streams, thus forcing a browser to
send video to the sink that the other victim expects will contain send video to the sink that the other victim expects will contain
audio (perhaps it is only expecting audio!) potentially causing audio (perhaps it is only expecting audio!) potentially causing
overload. Muxing multiple media flows over a single transport makes overload. Muxing multiple media flows over a single transport makes
it harder to individually suppress a single flow by denying ICE it harder to individually suppress a single flow by denying ICE
keepalives. Media-level (RTCP) mechanisms must be used in this case. keepalives. Media-level (RTCP) mechanisms must be used in this case.
[TODO: Write up Magnus's ICE forking attack when we get some clarity
on it.]
Note that attacks based on confusing one end or the other about Note that attacks based on confusing one end or the other about
consent are possible primarily even in the face of the third-party consent are possible primarily even in the face of the third-party
identity mechanism as long as major parts of the signaling messages identity mechanism as long as major parts of the signaling messages
are not signed. On the other hand, signing the entire message are not signed. On the other hand, signing the entire message
severely restricts the capabilities of the calling application, so severely restricts the capabilities of the calling application, so
there are difficult tradeoffs here. there are difficult tradeoffs here.
7. Acknowledgements 7. Acknowledgements
Bernard Aboba, Harald Alvestrand, Cullen Jennings, Hadriel Kaplan, Bernard Aboba, Harald Alvestrand, Cullen Jennings, Hadriel Kaplan,
Matthew Kaufman, Magnus Westerland. Matthew Kaufman, Magnus Westerland.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.abarth-origin]
Barth, A., "The Web Origin Concept",
draft-abarth-origin-09 (work in progress), November 2010.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-01 (work in progress), draft-ietf-rtcweb-security-01 (work in progress),
October 2011. October 2011.
[I-D.muthu-behave-consent-freshness]
Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for
Consent Freshness",
draft-muthu-behave-consent-freshness-00 (work in
progress), March 2012.
[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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011.
8.2. Informative References 8.2. Informative References
[I-D.ietf-hybi-thewebsocketprotocol] [I-D.ietf-rtcweb-jsep]
Fette, I. and A. Melnikov, "The WebSocket protocol", Uberti, J. and C. Jennings, "Javascript Session
draft-ietf-hybi-thewebsocketprotocol-17 (work in Establishment Protocol", draft-ietf-rtcweb-jsep-00 (work
progress), September 2011. in progress), March 2012.
[I-D.jennings-rtcweb-signaling] [I-D.jennings-rtcweb-signaling]
Jennings, C., Rosenberg, J., Uberti, J., and R. Jesup, Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/
"RTCWeb Offer/Answer Protocol (ROAP)", Answer Protocol (ROAP)",
draft-jennings-rtcweb-signaling-01 (work in progress), draft-jennings-rtcweb-signaling-01 (work in progress),
October 2011. October 2011.
[I-D.kaufman-rtcweb-security-ui] [I-D.kaufman-rtcweb-security-ui]
Kaufman, M., "Client Security User Interface Requirements Kaufman, M., "Client Security User Interface Requirements
for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in for RTCWEB", draft-kaufman-rtcweb-security-ui-00 (work in
progress), June 2011. progress), June 2011.
[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-00 (work in Interface", draft-rescorla-rtcweb-generic-idp-00 (work in
progress), January 2012. progress), January 2012.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Security", RFC 4347, April 2006. Layer Security (TLS)", RFC 5705, March 2010.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
for Establishing a Secure Real-time Transport Protocol RFC 6455, December 2011.
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[XmlHttpRequest] [XmlHttpRequest]
van Kesteren, A., "XMLHttpRequest Level 2". van Kesteren, A., "XMLHttpRequest Level 2".
Author's Address Author's Address
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
 End of changes. 22 change blocks. 
84 lines changed or deleted 110 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/