Internet DRAFT - draft-erdtman-ace-certificate-credential
draft-erdtman-ace-certificate-credential
ACE Working Group S. Erdtman, Ed.
Internet-Draft April 5, 2016
Intended status: Informational
Expires: October 7, 2016
Certificate credentials for ACE framework
draft-erdtman-ace-certificate-credential-00
Abstract
This draft provides an example of how to extend the ACE framework
[I-D.ietf-ace-oauth-authz], to use client and server certificates
(x509), for mutual authentication. Certificate are used to establish
the security context between the client and resource server. This
draft is limited to transport layer security based on DTLS and it
does not consider the mixed case where e.g. only the server is
authenticated with a certificate.
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 October 7, 2016.
Copyright 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
include Simplified BSD License text as described in Section 4.e of
Erdtman Expires October 7, 2016 [Page 1]
Internet-Draft Abbreviated Title April 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. x5t and x5t#256 . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. CBOR types . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. CBOR types . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
3.1. Token endpoint . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. CBOR Mappings . . . . . . . . . . . . . . . . . . . . 4
3.2. JWT and CWT . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. CWT CBOR key registration . . . . . . . . . . . . . . 5
3.3. Token Introspection . . . . . . . . . . . . . . . . . . . 6
3.3.1. CBOR Mappings . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Certificates is the dominant way to secure TLS connections. TLS is
mostly used to establish the identity of the Server, by connecting
the DNS name to the server certificate. The client can optional be
asked to provide its identity based on a certificate, but the common
way is to establish the client/user identity on the application
layer. In IoT space the limitation of devices makes the mixed
solution with application layer and transport layer security complex.
It is therefore common to do both client and server authentication on
the same layer.
This draft details on how the authorisation server can be leveraged
to provide the trust anchors between client and resources server when
setting up a connection. The result is similar to DANE RFC 6698
[RFC6698], where the DNS server provides the trust anchor.
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].
Erdtman Expires October 7, 2016 [Page 2]
Internet-Draft Abbreviated Title April 2016
2. x5t and x5t#256
The authorisation server is the common point in OAuth 2.0 with
relation to both the client and the resource server. It needs to
have a way to communicate the certificate (x509) trust anchors to the
client and the resource server. Communication with the client is
done with the Token endpoint where the client gets the token. The
resource server can either get the trust anchor information as part
of a self contained token or as a new attribute from the
introspection endpoint.
For the transport of the two new attributes are defined, x5t and
x5t#256. These are defined and registered in the appropriate IANA
registry
The attributes are defined as in defined in RFC 7519 [RFC7519] a
base64url encoded thumbprint of the x509 certificate. In this
context the thumbprint is used to identify the client-, server-,
issuer or root certificate of the server and the connecting client.
In cases where the transport is CBOR based the encoding of these
parameters is CBOR byte string, without the base64url encoding.
2.1. CBOR types
Validation of the trust chain MUST be done according to PKIX [TODO
insert reference] both on client and server side. With the exception
that the traversing of the certificate chain stops when a certificate
with the matching thumbprint is found.
If the x5t value in a token is
88234efc198f455848fa728fbde3ce549be1e7b4, the server first validates
the user certificate but does not stop there. It continues through
the chain to the Issuer CA certificate where it finds a match to the
thumbprint. With the match it does not continue up to the Root CA.
The x5t can be any of the certificates in the chain. How the client
and resource sever obtains the chain is out of scope for this
specification.
- Root CA (x5t = c16aab9fe3288df0fb8fc1d24990a300b6b8f299)
- Issuer CA (x5t = 88234efc198f455848fa728fbde3ce549be1e7b4)
- Server/Client Cert (x5t = 10f7158b7813470820325004d4637f7287dc1f63)
Figure 1: Certificate chain example
Erdtman Expires October 7, 2016 [Page 3]
Internet-Draft Abbreviated Title April 2016
2.2. CBOR types
When using CBOR encoding, values must be encoded with major type
according to table.
/--------------+-----------------------\
| Major Type | Key |
|--------------+-----------------------|
| 2 | x5t |
| 2 | x5t#256 |
\--------------+-----------------------/
Figure 2: CWT CBOR key values
3. IANA Considerations
This section contains registrations to the different registries where
the parameters are be used.
3.1. Token endpoint
The x5t or x5t#256 parameter is included in the token request and
returned in the token response. In the token response it is used to
validate the server certificate provided in the DTLS handshake
between client and resource server. In the token request it is to be
included in the access token or the token introspection response. To
aid the resource server in validating the client certificate in the
DTLS handshake between client and resource server.
o Parameter name: "x5t"
o Parameter usage location: token response and token request
o Change Controller: IESG
o Specification Document(s): this document
o Parameter name: "x5t#256"
o Parameter usage location: token response and token request
o Change Controller: IESG
o Specification Document(s): this document
3.1.1. CBOR Mappings
When token response is CBOR encoded according the the ACE framework
the following key values MUST be used.
TODO register values in ACE framework registry
o Claim name: "x5t"
o CBOR key value: X
Erdtman Expires October 7, 2016 [Page 4]
Internet-Draft Abbreviated Title April 2016
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Claim name: "x5t#256"
o CBOR key value: Y
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
3.2. JWT and CWT
When the x5t or x5t#256 parameter is included in the token it is used
to validate the client certificate provided in the DTLS handshake.
o Claim Name: "x5t"
o Claim Description: X.509 certificate SHA-1 thumbprint defined as
in RFC 7519 [RFC7519] but used to validate the client certificate
provided in the DTLS handshake.
o Change Controller: IESG
o Specification Document(s): this document
o Claim Name: "x5t#S256"
o Claim Description: X.509 certificate SHA-256 thumbprint defined as
in RFC 7519 [RFC7519] but used to validate the client certificate
provided in the DTLS handshake.
o Change Controller: IESG
o Specification Document(s): this document
3.2.1. CWT CBOR key registration
When encoded in a CWT following key values MUST be used.
TODO register key values in CWT registry
o Claim name: "x5t"
o CBOR key value: 8
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Claim name: "x5t#256"
o CBOR key value: 9
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
Erdtman Expires October 7, 2016 [Page 5]
Internet-Draft Abbreviated Title April 2016
3.3. Token Introspection
When the x5t or x5t#256 parameter is returned in the introspection
response it is used to validate the client certificate provided in
the DTLS handshake.
o Name: "x5t"
o Description: X.509 certificate SHA-1 thumbprint defined as in RFC
7519 [RFC7519] but used to validate client certificate provided in
the DTLS handshake.
o Change Controller: IESG
o Specification Document(s): this document
o Name: "x5t#S256"
o Description: X.509 certificate SHA-256 thumbprint defined as in
RFC 7519 [RFC7519] but used to validate the client certificate
provided in the DTLS handshake.
o Change Controller: IESG
o Specification Document(s): this document
3.3.1. CBOR Mappings
When token response is CBOR encoded according the the ACE framework
the following key values MUST be used.
TODO register values in ACE framework registry
o Claim name: "x5t"
o CBOR key value: X
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Claim name: "x5t#256"
o CBOR key value: Y
o CBOR major type: 2
o Change Controller: IESG
o Specification Document(s): this document
4. Acknowledgements
TBD
5. Security Considerations
TBD
Erdtman Expires October 7, 2016 [Page 6]
Internet-Draft Abbreviated Title April 2016
6. References
6.1. Normative References
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authorization for the Internet of Things
using OAuth 2.0", draft-ietf-ace-oauth-authz-01 (work in
progress), February 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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<http://www.rfc-editor.org/info/rfc7662>.
6.2. Informative References
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
Appendix A. Example
This sections provides a non normative examples of the flow and the
different connections
TBD
Author's Address
Samuel Erdtman (editor)
SE
Phone: +46702691499
Email: samuel@erdtman.se
Erdtman Expires October 7, 2016 [Page 7]
