Internet DRAFT - draft-yu-oauth-token-translation
draft-yu-oauth-token-translation
Network Working Group T. Yu
Internet-Draft MIT-KIT
Intended status: Standards Track November 30, 2014
Expires: June 3, 2015
A Kerberos Token Translation Service for OAuth
draft-yu-oauth-token-translation-01
Abstract
This document describes a Token Translation Service that allows a
site to use an existing Kerberos infrastructure to provide
authentication in an OAuth 2.0 web service environment.
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 June 3, 2015.
Copyright Notice
Copyright (c) 2014 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.
Yu Expires June 3, 2015 [Page 1]
Internet-Draft Token Translation Service November 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Claim Translation . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Principal Names . . . . . . . . . . . . . . . . . . . . . 3
4.2. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Authorization Data . . . . . . . . . . . . . . . . . . . 4
4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
An OAuth 2.0 client and an OAuth 2.0 authorization server could be
registered within the same Kerberos realm, or be registered in
Kerberos realms that share a cross-realm key. The following is a
description of how a site could leverage an existing Kerberos
infrastructure to provide authentication in an OAuth 2.0 web service
environment.
The Token Translation Service (TTS) allows an OAuth client to submit
a Kerberos service ticket and receive an OAuth Proof-of-Possession
token for the authorization server in return. The TTS can be
integrated into the Kerberos KDC, or it can be a standalone service
that has a copy of the Kerberos long-term service key of the OAuth
authorization server. The latter scenario has better security
properties because it uses the least amount of privilege required for
providing the service.
2. 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].
3. Overview
The client submits a request to the TTS that contains the Kerberos
ticket. The client need not be able to decode the Kerberos ticket
itself; as long as it somehow obtains a copy of the session key from
within the ticket, it can use the resulting OAuth Proof-of-Possession
token without having any knowledge of Kerberos encodings.
Yu Expires June 3, 2015 [Page 2]
Internet-Draft Token Translation Service November 2014
Example request
POST /tts HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
ticket=YX8wfaADAgEFoQ0bC0VYQU1QTEUuQ09N...
Example reply
HTTP/1.1 200 OK
Content-Type: application/jwt
eyJhbGciOiJub25lIn0....
The client can use the resulting Proof-of-Possession token to contact
the OAuth Authorization Server to receive tokens to access Resource
Servers. This can involve using the OAuth Authorization Server to
gain further Proof-of-Possession tokens for resource servers as
described in draft-bradley-oauth-pop-key-distribution.
Alternatively, the TTS could provide OAuth Access Tokens that are
Proof-of-Possession tokens, and the client could use them to access
the OAuth Resource Server directly using a protocol such as described
in draft-ietf-oauth-signed-http-request.
4. Claim Translation
[ This section specifies a mapping between fields of a Kerberos
ticket and JWT claims . Related protocols could use this mapping to
translate JWT claims into Kerberos ticket fields or vice versa. ]
4.1. Principal Names
Kerberos principal names have some amount of structure, so they will
generally need to be "flattened" to a single string encoding for use
in JWT claims. For translating Kerberos principal names into JWT
claims, the TTS SHOULD use the procedure in RFC 1964 section 2.1.3
("Exported Name Object Form for Kerberos V5 Mechanism"). The TTS MAY
provide alternative, possibly site-configured, mappings from
principal names into JWT claims.
The TTS SHOULD translate the Kerberos client principal name (the
cname and crealm fields of the ticket) to the JWT "sub" (subject)
claim. The TTS SHOULD translate the Kerberos server principal name
(the sname and realm fields of the ticket) to the JWT "aud"
(audience) claim. The TTS SHOULD translate the principal name of the
Yu Expires June 3, 2015 [Page 3]
Internet-Draft Token Translation Service November 2014
Ticket Granting Service (TGS) for the client's realm to the JWT "iss"
(issuer) claim.
4.2. Timestamps
The ticket authtime is translated to the JWT "iat" claim. The ticket
starttime is translated to the JWT "nbf" claim. The ticket endtime
is translated to the JWT "exp" claim. There is no JWT claim
corresponding to the ticket renew-till timestamp, so a new one would
need to be registered if this attribute is to be translated.
4.3. Addresses
Embedding IP addresses in Kerberos tickets is largely obsolescent, so
the JWT won't contain them. The TTS SHOULD refuse to translate
Kerberos tickets that contain IP addresses in the caddr field.
4.4. Authorization Data
Translations for Kerberos authorization data will need to be
configured on the TTS if needed, because there is no general way to
translate Kerberos authorization data into a form that is useful to
an OAuth Authorization Server. Additional specifications can define
procedures for translating a given Kerberos authorization data type
to JWT format.
4.5. Example
For example, a Kerberos ticket with client name (cname) "someuser"
and client realm (crealm) "EXAMPLE.COM", service name (sname) "HTTP/
as.example.com" and realm "EXAMPLE.COM", authtime of 20010101000000Z
and endtime of 20010101100000Z, would result in a JWT containing the
following fields:
{
"iss": "krbtgt/EXAMPLE.COM@EXAMPLE.COM",
"sub": "someuser@EXAMPLE.COM",
"aud": "HTTP/as.example.com@EXAMPLE.COM",
"exp": 978343200,
"iat": 978307200,
"cnf": {
"jwk": {
"kty": "oct",
"k": "AADerb7vyv4",
"alg": "A128GCM"
}
}
}
Yu Expires June 3, 2015 [Page 4]
Internet-Draft Token Translation Service November 2014
5. Key Management
The RFC 3961 pseudo-random function (PRF) for a given Kerberos
enctype will be used to produce any symmetric keys to be used with
JWE or JWS in conjunction with the resulting JWT. The input octet
string for the PRF for this purpose will be "tts.jwt." with the JWK
encryption algorithm name appended. At least the Kerberos session
key will be translated in this way. If the JWT is encrypted using
JWE, the symmetric key for that will also be derived from the long-
term Kerberos key for the service in this way.
Typically, the TTS produces a JWT that is a JWE token, so the
contents of the JWT are encrypted. Alternatively, the TTS could
produce a plaintext JWS token, but in that case the JWK for the "cnf"
claim MUST be protected using a key wrap algorithm.
6. Security Considerations
The Token Translation Service SHOULD be implemented as a standalone
service that has access to the relevant individual Kerberos service
principal key, rather than integrated into the Kerberos KDC. This
allows the TTS to operate at the lowest privilege level required for
its task, and prevents a compromise of the TTS from affecting parts
of the Kerberos infrastructure that do not depend on it.
The service principal name of a Kerberos ticket is not
cryptographically protected, because it is only used to locate a
decryption key. In Kerberos, services are presumed to have unique,
strongly random keys. If an OAuth server depends on having the "aud"
claim correctly reflect the service principal, the TTS MUST ensure
that the service key is unique and is correctly associated with the
principal name in the "aud" claim.
7. Normative References
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms-31 (work in progress), July 2014.
[I-D.ietf-jose-json-web-encryption]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption-31 (work in progress),
July 2014.
[I-D.ietf-jose-json-web-key]
Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key-31 (work in progress), July 2014.
Yu Expires June 3, 2015 [Page 5]
Internet-Draft Token Translation Service November 2014
[I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature-31
(work in progress), July 2014.
[I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-25 (work in
progress), July 2014.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
Author's Address
Tom Yu
MIT Consortium for Kerberos and Internet Trust
Email: tlyu@mit.edu
Yu Expires June 3, 2015 [Page 6]
