Transport Layer Security M. Williams
Internet-Draft J. Barrett
Intended status: Standards Track Nokia
Expires: September 5, 2009 March 4, 2009
Mobile DTLS
draft-barrett-mobile-dtls-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Mobile DTLS (Mobi-D) is an extension to DTLS that provides host
mobility support. After obtaining a new IP address or port, a DTLS
client mobile host can continue sending to its DTLS server
Williams & Barrett Expires September 5, 2009 [Page 1]
Internet-Draft Mobile DTLS March 2009
correspondent host. The mobile host continues to use the existing
set of security parameters, from the new address, without re-
negotiation. The correspondent host accepts packets from the new IP
address or port, also without re-negotiation. After receiving any
valid DTLS packet from the mobile host's new address or port, the
correspondent host uses the new address or port to send to the mobile
host.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Mobility Extension . . . . . . . . . . . . . . . . . . . . 4
2.2. OP Extension . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. New Message . . . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. System Diagram . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Example Flow . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Usage: Single Interface Host . . . . . . . . . . . . . . . 7
3.4. Usage: Multi-Interface Host . . . . . . . . . . . . . . . 7
4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Message . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Connection ID . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Williams & Barrett Expires September 5, 2009 [Page 2]
Internet-Draft Mobile DTLS March 2009
1. Introduction
Mobility service for hosts is available at the network layer from
Mobile IP and from Proxy Mobile IP. For cases when neither of those
mobility solutions are available, Mobi-D provides alternative
mobility, at the transport layer.
Applications are now carrying audio and video over UDP for the
benefits of low latency, help with NAT traversal, and where
reliability has to be done at a higher layer. These applications are
also being adapted for mobile devices, including multi-access devices
such as those with both wired and wireless interfaces, or those with
a wireless local area interface and a wireless wide area interface.
Mobi-D extends DTLS [RFC4347] to provide host based mobility for the
secure transport provided by DTLS. Mobi-D adds a connection
identifier (ID) to the DTLS record layer. The connection ID is used
for efficient indexing of the security parameters of a DTLS flow
between the hosts. By associating packets to a flow based on
security parameters instead of IP address and port, the connection
can be maintained across change of the IP address, port, or change of
interface.
A basic principle of Mobi-D is that no special messages are required
to inform the correspondent host of a mobile host's move. Receipt of
a fully valid Mobi-D record from the new address and port is
sufficient. The mobile host can move without any re-negotation, and
the other end can react immediately upon receipt of the first packet
from the new address/port. An additional benefit is that
applications on the mobile host can choose to ignore whether or not
they are moving, and just make the assumption that the operating
system has some address.
In whichever cases DTLS might be useful for securing UDP traffic,
Mobi-D extends those cases to support mobile hosts and multi access
hosts.
The terms "client" and "server" are used as in DTLS. In this
document a mobile host may have the role of DTLS client or server,
but will typically take the client role. In other words, mobility
support is not limited to client roles, either role may be mobile.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
Williams & Barrett Expires September 5, 2009 [Page 3]
Internet-Draft Mobile DTLS March 2009
2. Overview
Mobi-D extends DTLS in four ways:
1. A new DTLS Hello extension (Mobility)
2. A new TLS Hello extension (OP)
3. An additional field in the Record Layer (connection_id)
4. A new type of message (OP)
2.1. Mobility Extension
The Mobility extension allows a client and server to negotiate and
establish mobility support for a DTLS connection.
The client allocates a unique connection_id associated with each DTLS
handshake. For each full DTLS handshake, the client includes the
connection_id in the Mobility extension, for use by the server when
sending to this client. Likewise, the server allocates a unique
connection_id and responds with a Mobility extension in ServerHello,
including the connection_id for use by the client.
If the server includes the Mobility extension in its ServerHello, the
client MUST include the server's connection_id in the very next
record sent in the session, and all subsequent records. Likewise,
the server MUST include the client's connection_id in the very next
record sent in the session, and all subsequent records.
The Mobility extension includes a MobilityType value, which allows
the server to declare that its address is fixed. If the server sends
MobilityType fixed, then the client MUST NOT adjust its idea of the
server's IP or port, even if a datagram is received from a different
IP or port. This allows us to prevent the DoS attack described in
the Security Considerations (Section 5) in one direction.
Clients which include the Mobility extension SHOULD include the OP
extension as well, to allow OP messages to be used in the connection.
Likewise, a server including Mobility SHOULD include OP as well, if
the client did so.
Because TLS is inherently bound to a single host/port quartet, this
extension MUST only be used with DTLS, and not with TLS. Any TLS
server which receives this extension MUST ignore it.
Williams & Barrett Expires September 5, 2009 [Page 4]
Internet-Draft Mobile DTLS March 2009
2.2. OP Extension
The OP extension allows a client and server to negotiate and
establish support for the OP message. The client MAY include the OP
extension in its ClientHello. The extension contains a list of
OpTypes supported by the client. The server MAY respond with the OP
extension in its ServerHello, containing the list of OpTypes to be
supported in the connection. The server's list is the intersection
of the set of OpTypes supported by the server with the list provided
by the client. If the intersection is nil, the server MUST NOT
include the OP extension in its ServerHello.
2.3. New Message
Mobi-D specifies a new type of TLS message to be used for intra-
protocol communication. The OP message consists of an OpType and
opaque op_data and is encrypted and compressed as per the current
connection state (like any other message). The OP message gets a new
content type (managed by IANA, see Section 6).
The OP message is extensible to allow for future use. Mobi-D
specifies one OpType, NOP (no-op), which is just an empty message.
OP messages MUST be consumed by the receiving DTLS implementation,
they are not delivered to the application.
If Mobility has been negotiated for the flow, the recipient of a NOP
message MUST use the message's source address and port as the
destination address and port for all new messages back to the sender.
The NOP message is then discarded.
3. Usage Model
3.1. System Diagram
TODO: this diagram needs explanation.
---------------- -------------------------
|Mobi-D client |SP(cidS)------->|Mobi-D server |
| mobile host |
Internet-Draft Mobile DTLS March 2009
from the client, to authenticate and decrypt the record.
The client also allocates a connection ID (cidC) for use by the
server. The server sends that ID in all records it sends to that
client. The client receives a record with the connection ID it
allocated, and uses that to look up the security parameters (SP) for
the DTLS flow from the server, to authenticate and decrypt the
record.
The terms server and client are used as in DTLS. However, the server
and client may both be mobile devices. Note that the flows are not
bound to or dependent on particular interfaces of the hosts.
3.2. Example Flow
In this example, the client changes IP address and the server
immediately begins sending traffic to the new address. For the sake
of simplicity, the "src" and "sport" examples given here are the
values seen by the server. Quite possibly the client is behind a NAT
and has a different address on its own interface.
Client Server
------ ------
Data ------>
(cid=100)
(src=208.16.24.2)
(sport=6723)
(cid=100)
(src=208.69.36.132)
(sport=8901)
Internet-Draft Mobile DTLS March 2009
3.3. Usage: Single Interface Host
For a single-interface mobile host (MH), when the host moves to a new
network and is assigned a new IP address, the MH can continue the
secure communication by using the new IP address with the old
security parameters. No signaling is needed, and the transport and
application will continue as soon as the MH is ready to use the new
IP address.
3.4. Usage: Multi-Interface Host
Mobi-D is not intended to allow two interfaces to carry a single DTLS
flow simultaneously. If the MH has a Mobi-D connection and needs to
continue that connection on a new interface, and has a different IP
address on the new interface, the MH can continue the secure
connection on the new interface by using the new IP address with the
old security parameters.
If the MH wants to use two or more interfaces at once, it perform the
DTLS handshake multiple times, allocating a unique connection_id for
each flow on each interface. This way the MH can create separate
Mobi-D connections for each of the flows from each interface.
Mobility that causes only one of the interfaces to need a change of
IP address is supported. For example, consider a mobile device with
a small cell radio such as WLAN and a large cell radio such as LTE or
WiMAX. Local mobility might cause the Mobi-D connection on the WLAN
to move to a new network and configure a new IP address, while the
larger cell is still in range and doesn't create a need to modify the
IP address. In this case the host can continue to use both Mobi-D
connections while updating the IP address on one.
In another multi-radio use case, the host may have two Mobi-D
connections on two different interfaces, but may lose coverage on one
of the radios. In this case the MH may use the interface that is
still in range and the IP address already available on that
interface. The MH begins sending the Mobi-D connection of the
failing interface over the working interface. There is no need to
get a new IP address, or re-handshake on the new interface to
accomodate the second flow.
The receiving host of a Mobi-D connection will typically be a server
of some kind, but may be another MH. The receiving host accepts
Mobi-D packets from any IP address. The connection to which the
inbound packet belongs is determined by the connection identifier and
corresponding security parameters. In the case of a server receiving
two inbound Mobi-D packets from the same client IP address, they will
belong to the same connection or to different connections depending
on the connection identifier and security parameters used by the MH
Williams & Barrett Expires September 5, 2009 [Page 7]
Internet-Draft Mobile DTLS March 2009
when transmitting.
If an MH is behind a NAT, the Mobi-D packets may have NATed IP
addresses or ports. These will still be delivered based on them
having a connection identifier and matching security parameters.
During and after the MH changes IP address, in-bound datagrams may be
lost, until the MH sends a packet to the receiving server or host to
cause the receiving host to add or update the new IP address to the
connection. This packet can be the next packet in the connection, or
can be a special Mobi-D NOP packet to optimize the remote host's
detection of the address change.
4. Details
4.1. Extensions
The Mobility and OP extensions follow the TLS Extension format as
defined in TLS [RFC5246]:
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
(65535)
} ExtensionType;
Williams & Barrett Expires September 5, 2009 [Page 8]
Internet-Draft Mobile DTLS March 2009
The Mobility extension, OP extension, and new ExtensionType are
defined as follows:
enum {
mobility(), op(), (65535)
} ExtensionType;
struct {
uint32 connection_id;
MobilityType mobile_type;
} Mobility;
enum { mobile(1), fixed(2), (255) } MobilityType;
struct {
uint8 length;
OpType<1..256> op_types;
} OP;
enum { nop(1), (255) } OpType;
The extension_type for Mobi-D is maintained by IANA as described in
the section on IANA considerations (Section 6).
4.2. Record Layer
Mobi-D adds a connection identifier to the DTLS record layer which
each host uses to look up the security parameters for the connection.
The identifier (connection_id) is a single 32-bit integer, placed
immediately after the content type.
TODO: should this handle collisions with non-Mobi-D DTLS records?
For example, certain values of the high order byte of connection_id
could be made illegal. The current placement in the record leaves
this possibility open.
The modified DTLS record layer is as follows. connection_id is always
the ID provided by the receiving party.
struct {
ContentType type;
uint32 connection_id; // New field
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
Williams & Barrett Expires September 5, 2009 [Page 9]
Internet-Draft Mobile DTLS March 2009
} DTLSPlaintext;
Once established, the connection_id remains in use throughout the
life of the DTLS session, including in a re-handshake. The client
MUST include the server's connection_id in every record sent to the
server, and likewise, the server MUST include the client's
connection_id in every record sent to the client.
If a host receives a valid Mobi-D record with a valid connection_id
from a new IP address or port, the host MUST use the message's source
address and port as the destination address and port for all new
messages back to the sender. A host MUST NOT change the destination
address and port for the correspondent host until after successfully
authenticating and verifying the sequence number of the DTLS record
according to the connection_id contained within.
A new handshake (either for session resumption or a full handshake)
MUST NOT use connection_ids in ClientHello and ServerHello because
the IDs will point to existing security parameters that do not yet
apply to the flow. The client and server MAY agree to re-use the
same connection_ids via the Mobility extension negotiation in the
handshake. Multiple connections between the same client and server
MUST use different connection_ids and security parameters.
However, a re-handshake during an established session MUST include
connection_ids in all records, as the connection_ids are necessary
for each party to find the current security parameters.
The introduction of the connection identifier creates the possibility
for an attacker with access to the packet flow to forward a packet
after modifying the IP address or port, causing the return packet to
be misaddressed. This attack is discussed further in the Security
Considerations section (Section 5) below.
4.3. Message
Mobi-D adds a new message to TLS: the OP message. OP MUST be
consumed by the receiving DTLS implementation and MUST NOT be
delivered to the application. OP is an extensible message; other
extensions may add OP message types. OP is implemented using a new
content type, op, provided by IANA (see Section 6). Like other
messages, op messages are encrypted and compressed, as specified by
the current connection state. Mobi-D defines the NOP (no-op) OP
message type.
Only OP message types negotiated in the OP Hello extension may be
sent in a connection.
Williams & Barrett Expires September 5, 2009 [Page 10]
Internet-Draft Mobile DTLS March 2009
The extended ContentType is as follows. The OP content type is
maintained by IANA as described in Section 6.
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), op(), (255)
} ContentType;
The OP message is defined as follows:
enum { nop(1), (255) } OpType;
struct {
OpType op_type;
opaque op_data<0..2^14-1>;
} OP;
5. Security Considerations
5.1. Cryptography
Mobi-D makes no changes to the cryptography of DTLS.
5.2. Connection ID
The connection_id has no cryptographic properties. An attacker able
to capture packets can modify the connection_id. A Mobi-D host that
receives a DTLS record with an incorrect (but valid) connection_id
will be unable to authenticate the record and will reject it. A
Mobi-D host that receives a record with an invalid connection_id (one
it does not recognize) MUST discard the record.
5.3. Denial of Service
Mobi-D introduces new DoS attack. An attacker able to capture
datagrams from the client will be able to send a valid datagram to
the server from a forged IP address. This will cause the server to
transmit packets to the forged address until the server receives a
new packet from the real client. The same attack can occur in the
other direction, but can be mitigated by the use of the fixed
MobilityType in the server's Mobility extension.
Such an attack could deny service to the victim(s), but would not
compromise the integrity of the encrypted data, nor allow the
attacker to inject data of his own choosing, or to replay datagrams.
Further, this attack is not substantially different from other denial
Williams & Barrett Expires September 5, 2009 [Page 11]
Internet-Draft Mobile DTLS March 2009
of service attacks.
6. IANA Considerations
The Mobility extension number, OP extension number, and the OP
content type will need to be registered with IANA.
7. Acknowledgements
The authors want to thank Pasi Eronen, Hannes Tschofenig, Basaravaj
(Raj) Patil, Dan Wing, Teemu Savolainen, Lars Eggert, and Eric
Rescorla
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Michael Williams
Nokia
Email: michael.g.williams@nokia.com
Jeremey Barrett
Nokia
Email: jeremey.barrett@nokia.com
Williams & Barrett Expires September 5, 2009 [Page 12]