Internet DRAFT - draft-jones-perc-dtls-id
draft-jones-perc-dtls-id
Network Working Group P. Jones
Internet-Draft Cisco Systems
Intended status: Standards Track N. Ohlmeier
Expires: September 14, 2017 Mozilla
March 13, 2017
Transporting the SDP attribute 'dtls-id' in TLS and DTLS
draft-jones-perc-dtls-id-00
Abstract
This draft defines a new extension to carry the "dtls-id" value
defined for use in the Session Description Protocol within TLS and
DTLS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright Notice
Copyright (c) 2017 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones & Ohlmeier Expires September 14, 2017 [Page 1]
Internet-Draft dtls-id in TLS and DTLS March 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . 2
3. Endpoint procedures . . . . . . . . . . . . . . . . . . . . . 3
4. Media distributor procedures . . . . . . . . . . . . . . . . 3
5. Key distributor procedures . . . . . . . . . . . . . . . . . 3
6. The dtls_id TLS extension . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 4
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Privacy-Enhanced RTP Conferencing (PERC) working group specified
a DTLS [RFC6347] tunneling mechanism [I-D.ietf-perc-dtls-tunnel] that
enables a media distributor to forward DTLS messages between an
endpoint and a key distributor. In the process, the media
distributor is able to securely receive only the hop-by-hop keying
material, while the endpoints are able to securely receive both end-
to-end and hob-by-hop keying material.
An open issue with the current design is how the key distributor can
determine which one of several conferences an endpoint is attempting
to join. The only information that the key distributor receives via
the DTLS tunnel is the endpoint's certificate. However, the same
certificate might be used to join several conferences in parallel,
thus creating a need for additional information.
[I-D.ietf-mmusic-dtls-sdp] defines an attribute in SDP [RFC4566]
called the "dlts-id". The "dtls-id" presented by the endpoint's in
SDP will be unique for each DTLS association established using the
same certificate. By signaling the certificate fingerprint and
"dtls-id" in SDP, along with including the same in the DTLS signaling
sent to the key distributor, it would be possible for the key
distributor to unambiguously determine which conference key the
endpoint should receive.
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
Jones & Ohlmeier Expires September 14, 2017 [Page 2]
Internet-Draft dtls-id in TLS and DTLS March 2017
The terms key distributor, media distributor, endpoint, conference,
hop-by-hop keying material, and end-to-end keying material used in
this document are introduced in
[I-D.ietf-perc-private-media-framework].
3. Endpoint procedures
The endpoint MUST include the "dtls_id" DTLS extension in the
"ClientHello" message when establishing a DTLS tunnel in a PERC
conference. Likewise, the "dtls-id" SDP attribute MUST be included
in SDP sent by the endpoint in both the offer and answer [RFC3264]
messages as per [I-D.ietf-mmusic-dtls-sdp].
When receiving a "dtls_id" value from the key distributor, the client
MUST check to ensure that value matches the "dtls-id" value received
in SDP. If the values do not match, the endpoint MUST consider any
received keying material to be invalid and terminate the DTLS
association.
4. Media distributor procedures
The media distributor is not required to inspect the "dtls_id"
extension, as it merely forwards DTLS messages between the endpoint
and the key distributor.
5. Key distributor procedures
This draft assumes that when the endpoint inserts the "dtls-id" into
SDP, the information will be conveyed in some way to the key
distributor. The process through which the "dtls-id" in SDP is
conveyed to the key distributor is outside the scope of this
document.
The key distributor MUST extract the "dtls_id" value transmitted in
the "ClientHello" message and match that against "dtls-id" value the
endpoint transmitted via SDP. If the values in SDP and the
"ClientHello" do not match, the DTLS association MUST be rejected.
The key distributor MUST correlate the certificate fingerprint and
"dtls_id" received from endpoint's "ClientHello" message with the
corresponding values received from the SDP transmitted by the
endpoint. It is through this correlation that the key distributor
can be sure to deliver the correct conference key to the endpoint.
When sending the "ServerHello" message, the key distributor MUST
insert its own "dtls-id" value. This value MUST also be conveyed
back to the client via SDP.
Jones & Ohlmeier Expires September 14, 2017 [Page 3]
Internet-Draft dtls-id in TLS and DTLS March 2017
6. The dtls_id TLS extension
The "dtls_id" TLS extension may be used either with TLS [RFC5246] or
DTLS. It carries only "dtls-id" value defined in
[I-D.ietf-mmusic-dtls-sdp] in the field called "dtls_id". The syntax
for the "dtls_id" extension is shown below.
struct {
opaque dtls_id<20..255>;
} SdpDtlsIdData;
7. IANA Considerations
This document registers an extension in the TLS "ExtensionType
Values" registry established in [RFC5246]. The extension is called
"dtls_id" and is assigned the code point TBD. The following addition
is made to the registry.
+-----------+-------------+-----------+---------------------+
| Extension | Recommended | TLS 1.3 | HelloRetryRequested |
+-----------+-------------+-----------+---------------------+
| dlts_id | Yes | Encrypted | Yes |
+-----------+-------------+-----------+---------------------+
8. Security Considerations
The "dtls-id" value is a random value that has no personal
identifiable information associated with it. Thus, the value does
not expose such information. It also has no particular security
properties in and of itself, so being in plaintext in the
"ClientHello" or "ServerHello" is not viewed as a security concern.
However, the value does have significance to the receiver, thus
changes to the "dtls-id" may result in unexpected behavior. For
example, if Alice attempts to join a PERC-enabled conference and the
"dtls_id" field is modified in route to the key distributor, Alice
may either fail to receive the conference key or receive the wrong
conference key. However, since Alice will only be provided keys for
conferences for which she is authorized to join based on her client
certificate, receiving the wrong key will not compromise the security
of the conference. However, receipt of the wrong key will deny Alice
access to the plaintext of media transmitted by other participants.
Additionally, if Alice transmits media using the wrong conference
key, the media will be undecipherable by other conference
participants.
As prescribed in these procedures, if the "dtls_id" field transmitted
from the key distributor to Alice is modified, Alice will tear down
Jones & Ohlmeier Expires September 14, 2017 [Page 4]
Internet-Draft dtls-id in TLS and DTLS March 2017
the DTLS association and fail to join the conference. The result is
a denial of service for Alice, but not worse than when any other part
of the DTLS message is modified.
9. Acknowledgments
The authors would like to thank Martin Thomson for discussing the
idea and providing some initial feedback before the draft was
written. We also want to express our appreciation to Cullen Jennings
for reviewing the text and providing constructive input.
10. Normative References
[I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer
Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-20 (work
in progress), February 2017.
[I-D.ietf-perc-dtls-tunnel]
Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
between a Media Distributor and Key Distributor to
Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-00
(work in progress), March 2017.
[I-D.ietf-perc-private-media-framework]
Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy Enhanced RTP
Conferencing", draft-ietf-perc-private-media-framework-02
(work in progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Jones & Ohlmeier Expires September 14, 2017 [Page 5]
Internet-Draft dtls-id in TLS and DTLS March 2017
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
Authors' Addresses
Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709
USA
Phone: +1 919 476 2048
Email: paulej@packetizer.com
Nils H. Ohlmeier
Mozilla
Phone: +1 408 659 6457
Email: nils@ohlmeier.org
Jones & Ohlmeier Expires September 14, 2017 [Page 6]
