draft-ietf-sip-dtls-srtp-framework-04.txt   draft-ietf-sip-dtls-srtp-framework-05.txt 
SIP J. Fischl SIP J. Fischl
Internet-Draft CounterPath Corporation Internet-Draft CounterPath Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 4, 2009 Nokia Siemens Networks Expires: May 2, 2009 Nokia Siemens Networks
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
October 1, 2008 October 29, 2008
Framework for Establishing an SRTP Security Context using DTLS Framework for Establishing an SRTP Security Context using DTLS
draft-ietf-sip-dtls-srtp-framework-04.txt draft-ietf-sip-dtls-srtp-framework-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2009. This Internet-Draft will expire on May 2, 2009.
Abstract Abstract
This document specifies how to use the Session Initiation Protocol This document specifies how to use the Session Initiation Protocol
(SIP) to establish an Secure Real-time Transport Protocol (SRTP) (SIP) to establish an Secure Real-time Transport Protocol (SRTP)
security context using the Datagram Transport Layer Security (DTLS) security context using the Datagram Transport Layer Security (DTLS)
protocol. It describes a mechanism of transporting a fingerprint protocol. It describes a mechanism of transporting a fingerprint
attribute in the Session Description Protocol (SDP) that identifies attribute in the Session Description Protocol (SDP) that identifies
the key that will be presented during the DTLS handshake. The key the key that will be presented during the DTLS handshake. The key
exchange travels along the media path as opposed to the signaling exchange travels along the media path as opposed to the signaling
skipping to change at page 16, line 6 skipping to change at page 16, line 6
This shows the initial INVITE from Alice to Bob carried over the This shows the initial INVITE from Alice to Bob carried over the
TLS transport protocol to ensure an integrity protected channel TLS transport protocol to ensure an integrity protected channel
between Alice and her proxy which acts as Alice's identity between Alice and her proxy which acts as Alice's identity
service. Note that Alice has requested to be either the active or service. Note that Alice has requested to be either the active or
passive endpoint by specifying a=setup:actpass. Bob chooses to passive endpoint by specifying a=setup:actpass. Bob chooses to
act as the DTLS client and will initiate the session. Also note act as the DTLS client and will initiate the session. Also note
that there is a fingerprint attribute in the SDP. This is that there is a fingerprint attribute in the SDP. This is
computed from Alice's self-signed certificate. computed from Alice's self-signed certificate.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS 192.0.2.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:alice@192.168.1.103:6937;transport=TLS> Contact: <sip:alice@192.0.2.103:6937;transport=TLS>
To: <sip:bob@example.com> To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.168.1.103 o=- 1181923068 1181923196 IN IP4 192.0.2.103
s=example1 s=example1
c=IN IP4 192.168.1.103 c=IN IP4 192.0.2.103
a=setup:actpass a=setup:actpass
a=fingerprint: \ a=fingerprint: \
SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
m=audio 6056 RTP/AVP 0 m=audio 6056 RTP/AVP 0
a=sendrecv a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
Message (2): INVITE Proxy -> Bob Message (2): INVITE Proxy -> Bob
skipping to change at page 17, line 6 skipping to change at page 17, line 6
Identity-Info header. This example only shows one element for Identity-Info header. This example only shows one element for
both proxies for the purposes of simplification. Bob verifies the both proxies for the purposes of simplification. Bob verifies the
identity provided with the INVITE. Note that this offer includes identity provided with the INVITE. Note that this offer includes
a default m-line offering RTP in case the answerer does not a default m-line offering RTP in case the answerer does not
support SRTP. However, the potential configuration utilizing a support SRTP. However, the potential configuration utilizing a
transport of SRTP is preferred. See transport of SRTP is preferred. See
[I-D.ietf-mmusic-sdp-capability-negotiation] for more details on [I-D.ietf-mmusic-sdp-capability-negotiation] for more details on
the details of SDP capability negotiation. the details of SDP capability negotiation.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS 192.168.1.101:5060;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS 192.0.2.101:5060;branch=z9hG4bK-0e53sadfkasldkfj
Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK-0e53244234324234 Via: SIP/2.0/TCP 192.0.2.100:5060;branch=z9hG4bK-0e53244234324234
Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Via: SIP/2.0/TCP 192.0.2.103:6937;branch=z9hG4bK-0e5b7d3edb2add32
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:alice@192.168.1.103:6937;transport=TLS> Contact: <sip:alice@192.0.2.103:6937;transport=TLS>
To: <sip:bob@example.com> To: <sip:bob@example.com>
From: "Alice"<sip:alice@example.com>;tag=843c7b0b From: "Alice"<sip:alice@example.com>;tag=843c7b0b
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k
3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC
HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI=
Identity-Info: https://example.com/cert Identity-Info: https://example.com/cert
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 1181923068 1181923196 IN IP4 192.168.1.103 o=- 1181923068 1181923196 IN IP4 192.0.2.103
s=example1 s=example1
c=IN IP4 192.168.1.103 c=IN IP4 192.0.2.103
a=setup:actpass a=setup:actpass
a=fingerprint: \ a=fingerprint: \
SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
m=audio 6056 RTP/AVP 0 m=audio 6056 RTP/AVP 0
a=sendrecv a=sendrecv
a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP
a=pcfg:1 t=1 a=pcfg:1 t=1
Message (3): ClientHello Bob -> Alice Message (3): ClientHello Bob -> Alice
Assuming that Alice's identity is valid, Line 3 shows Bob sending Assuming that Alice's identity is valid, Line 3 shows Bob sending
a DTLS ClientHello(s) directly to Alice. In this case two DTLS a DTLS ClientHello(s) directly to Alice. In this case two DTLS
ClientHello messages would be sent to Alice: one to ClientHello messages would be sent to Alice: one to 192.0.2.103:
192.168.1.103:6056 for RTP and another to port 6057 for RTCP, but 6056 for RTP and another to port 6057 for RTCP, but only one arrow
only one arrow is drawn for compactness of the figure. is drawn for compactness of the figure.
Message (4): ServerHello+Certificate Alice -> Bob Message (4): ServerHello+Certificate Alice -> Bob
Alice sends back a ServerHello, Certificate, ServerHelloDone for Alice sends back a ServerHello, Certificate, ServerHelloDone for
both RTP and RTCP associations. Note that the same certificate is both RTP and RTCP associations. Note that the same certificate is
used for both the RTP and RTCP associations. If RTP/RTCP used for both the RTP and RTCP associations. If RTP/RTCP
multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] were being used only
a single association would be required. a single association would be required.
Message (5): Certificate Bob -> Alice Message (5): Certificate Bob -> Alice
skipping to change at page 19, line 9 skipping to change at page 19, line 9
contains the fingerprint for Bob's certificate. When Alice contains the fingerprint for Bob's certificate. When Alice
receives the message and validates the certificate presented in receives the message and validates the certificate presented in
Message 7. The endpoint now shows Alice that the call as secured. Message 7. The endpoint now shows Alice that the call as secured.
Note that in this case, Bob signals the actual transport protocol Note that in this case, Bob signals the actual transport protocol
configuration of SRTP over DTLS in the acfg parameter. configuration of SRTP over DTLS in the acfg parameter.
SIP/2.0 200 OK SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=6418913922105372816 To: <sip:bob@example.com>;tag=6418913922105372816
From: "Alice" <sip:alice@example.com>;tag=843c7b0b From: "Alice" <sip:alice@example.com>;tag=843c7b0b
Via: SIP/2.0/TCP 192.168.1.103:6937;branch=z9hG4bK-0e5b7d3edb2add32 Via: SIP/2.0/TCP 192.0.2.103:6937;branch=z9hG4bK-0e5b7d3edb2add32
Call-ID: 6076913b1c39c212@REVMTEpG Call-ID: 6076913b1c39c212@REVMTEpG
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:192.168.1.104:5060;transport=TCP> Contact: <sip:192.0.2.104:5060;transport=TCP>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: xxxx Content-Length: xxxx
v=0 v=0
o=- 6418913922105372816 2105372818 IN IP4 192.168.1.104 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.104
s=example2 s=example2
c=IN IP4 192.168.1.104 c=IN IP4 192.0.2.104
a=setup:active a=setup:active
a=fingerprint:\ a=fingerprint:\
SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB SHA-1 FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
t=0 0 t=0 0
m=audio 12000 UDP/TLS/RTP/SAVP 0 m=audio 12000 UDP/TLS/RTP/SAVP 0
a=acfg:1 t=1 a=acfg:1 t=1
Message (9): RTP+RTCP Alice -> Bob Message (9): RTP+RTCP Alice -> Bob
At this point, Alice can also start sending RTP and RTCP to Bob. At this point, Alice can also start sending RTP and RTCP to Bob.
skipping to change at page 27, line 21 skipping to change at page 27, line 21
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[I-D.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-09 (work in progress), draft-zimmermann-avt-zrtp-10 (work in progress),
September 2008. October 2008.
[I-D.mcgrew-srtp-ekt] [I-D.mcgrew-srtp-ekt]
McGrew, D., "Encrypted Key Transport for Secure RTP", McGrew, D., "Encrypted Key Transport for Secure RTP",
draft-mcgrew-srtp-ekt-03 (work in progress), July 2007. draft-mcgrew-srtp-ekt-03 (work in progress), July 2007.
[I-D.ietf-avt-dtls-srtp] [I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)", Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-05 (work in progress), draft-ietf-avt-dtls-srtp-05 (work in progress),
 End of changes. 18 change blocks. 
23 lines changed or deleted 23 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/