ACE Working Group L. Seitz
SICS Swedish ICT
Internet-Draft April 12, 2016
Intended Status: Standards Track
Expires: October 14, 2016
Transporing access tokens in session resumption tickets
draft-seitz-ace-ticket-token-transfer-00 (TTT)
Abstract
This memo presents a method of transferring an access token from a
client to a resource server in a (D)TLS handshake, based on Session
Resumption without Server-Side State (RFC 5077).
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2016 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
Seitz, L. Expires October 14, 2016 [Page 1]
INTERNET DRAFT Ticket-based token transport April 12, 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Ticket format . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1 Normative References . . . . . . . . . . . . . . . . . . . 5
10.2 Informative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Seitz, L. Expires October 14, 2016 [Page 2]
INTERNET DRAFT Ticket-based token transport April 12, 2016
1. Introduction
The default way of transferring an OAuth access token to a resource
server (RS) via CoAP is defined in [I-D.ietf-ace-oauth-authz] as
POSTing to a well-known resource, namely /authz-info on the RS. This
solution might not be ideal in all cases, as it requires an extra
message exchange and the RS needs to perform a lookup when the
request arrives to determine which token matches this request.
Therefore this memo describes how to transfer an access token inside
a server state ticket used for (D)TLS session resumption without
server state [RFC5077].
1.1 Terminology
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]. These
words may also appear in this document in lowercase, absent their
normative meanings.
2. Ticket format
The StatePlaintext structure from section 4 of RFC 5077 is modified
as follows:
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
uint16 access_token_length;
opaque access_token;
} StatePlaintext;
Where the access_token field contains a representation of the access
token, readable for the RS, and the access_token_length field gives
the length of this token in bytes.
Furthermore the following changes are made to
ClientAuthenticationType structure in order to support raw public
keys (RPK):
enum {
anonymous(0),
certificate_based(1),
psk(2),
Seitz, L. Expires October 14, 2016 [Page 3]
INTERNET DRAFT Ticket-based token transport April 12, 2016
rpk(3)
} ClientAuthenticationType;
Finally the ClientIdentity structure is modified as follows, also to
support RPK:
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
case rpk:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
/* from [RFC7250] */
};
} ClientIdentity;
All other parts of RFC 5077 remain unchanged. The RS MUST process
the ticket as specified in RFC 5077, and additionally it MUST verify
the validity of the token contained in the access_token field, and if
it is valid it MUST store it for future use. The validity check MUST
include a check of the token binding to the client identity given in
the client_identity field. If the token is not a bearer token, the
RS MUST reject a ClientAuthenticationType of anonymous and abort the
handshake with an illegal_parameter error.
3. Security Considerations
All security considerations from RFC 5077 apply equally to this memo.
Furthermore the methods for verifying the validity of an access
token may vary widely depending on the token type. Implementers
should carefully consider how to avoid mixing up different token
types (e.g. bearer tokens vs proof-of-possession tokens) which
require different verification methods. Resource Servers MUST NOT
accept a session resumption ticket containing a token for which the
RS can not determine the validity (e.g. because it cannot interpret
the token format).
4. Privacy Considerations
The privacy considerations from RFC 5077 apply equally to this memo.
The length of the ticket might leak information about the fact that
it contains a access token, and possibly about the format and
Seitz, L. Expires October 14, 2016 [Page 4]
INTERNET DRAFT Ticket-based token transport April 12, 2016
contents of the token. Adversaries having good knowledge of the
different possible access tokens in a specific application, could
determine which kind of access the token authorizes based on its
length. If such attacks are of concern, a padding method for the
token should be considered.
5. IANA Considerations
This document does not require any actions or assignments from IANA.
6. Acknowledgements
Jim Schaad originally suggested this approach, and Hannes Tschofenig
explained the rudimentary details at IETF 95.
7. References
10.1 Normative References
[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>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
10.2 Informative References
Author's Address
Ludwig Seitz
Seitz, L. Expires October 14, 2016 [Page 5]
INTERNET DRAFT Ticket-based token transport April 12, 2016
SICS Swedish ICT AB
Scheelevagen 17
22370 Lund
SWEDEN
EMail: ludwig@sics.se
Seitz, L. Expires October 14, 2016 [Page 6]