| Network Working Group | N. Williams |
| Internet-Draft | Cryptonector |
| Intended status: Standards Track | October 24, 2014 |
| Expires: April 27, 2015 |
Public Key-Based Kerberos Cross Realm Path Traversal Protocol Using Kerberized Certification Authorities (kx509) and PKINIT
draft-williams-kitten-krb5-pkcross-03
This document specifies a protocol for obtaining cross-realm Kerberos tickets using existing, related protocols: kerberized certification authorities (kx509) and public key cryptography initial authentication in Kerberos (PKINIT). The resulting protocol has a number of desirable properties, primarily that it allows Kerberos to scale to large numbers of realms.
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 April 27, 2015.
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.
Kerberos [RFC4120] supports meshes of many realms. The individual relationships between realms must be manually keyed, usually with keys derived from passwords. A full mesh wouldn't scale, therefore the protocol calls for hierarchical trust hierarchies. In practice non-hierarchical but also non-fully-meshed relationships are used.
These manually-exchanged keys are very difficult to rollover safely, and when they are changed the result is often outages -- controlled outages where foreseen, but outages nonetheless.
Manual cross-realm keying does not scale, and has very poor security properties. We seek to remediate this using public key cryptography, building on existing Kerberos specifications.
Many years ago there was a proposal for exchanging cross-realm keys using a public key infrastructure (PKI) [RFC5280]; that proposal went by the name “PKCROSS”. We appropriate that long-dead proposal's name, but the protocol specified here is very different from the original proposal.
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].
We provide two variants of the PKCROSS protocol: one that is client-driven, and another that is driven by a Ticket Granting Service (TGS) on behalf of its clients. The latter is based on the former, with the TGS acting as a client. We begin with the client-driven case. DNS-Based Authentication of Named Entities (DANE) [RFC6698] can and should be used for realm CA certificate validation.
A Kerberos client in with a ticket-granting ticket (TGT) for any one source realm (usually but not necessarily the client's own realm) wishing to acquire a TGT for a destination realm may use this protocol instead of the traditional cross-realm ticket-granting service (TGS) exchanges as follows:
If the destination realm issues the requested Ticket then it SHOULD include the client's certificate in an AD-CLIENT-CERTIFICATE authorization-data element, and it MUST do so if it does not validate the client's certificate to an acceptable trust anchor. The AD-CLIENT-CERTIFICATE authorization-data MUST be in a KDC-signed authorization-data container [XXX add reference to CAMMAC].
[CREF1]QUESTION: Should the PKINIT request in step #3 be a TGS-REQ with PKINIT pre-auth data?
[CREF2]QUESTION: Should the PKINIT request in step #3 be required to be used within a FAST tunnel?
A TGS can bootstrap ephemeral cross-realm trust principals on behalf of its clients. This allows the cost of PKCROSS to be amortized over many clients, and it allows participation by clients that do not support client-driven PKCROSS (or whose PKCROSS requests are rejected by the target).
In this mode the TGS uses the client-driven PKCROSS protocol, modified as follows:
The resulting TGT -which we shall term an “issuer TGT” (ITGT)- and its session key can then be used by the source TGS to create cross-realm TGTs for the source-to-target trust principal (“krbtgt/TARGET@SOURCE”).
This ITGT will be used to mint tickets as described below.
Cross-realm TGTs issued by a source TGS using an ITGT will not be quite like normal Kerberos Tickets: their encrypted part contains an AP-REQ using the ITGT acquired by the source TGS, and this AP-REQ is “encrypted” with the null enctype, The AP-REQ's Authenitcator MUST contain an authorization-data element that carries a) the name of the client principal, b) the session key that the client should be using with the cross-realm TGTs issued.
AD-PKCROSS-TGT-INFO ::= SEQUENCE {
cname [0] Principal, -- the client's realm is the
-- crealm from the ITGT's EncTicketPart
key [1] EncryptionKey
}
Figure 1: AD-PKCROSS-TGT-INFO
Because the process of acquiring an ITGT might be slow, a TGS doing so on behalf of a client could use a mechanism for instructing the client to be patient. Existing clients would not handler a new error code by waiting, therefore there is not much that can be done to keep an impatient client from retrying at another KDC.
The existing KDC_ERR_SVC_UNAVAILABLE error code cannot be used as often this causes the client to immediately retry the request at another KDC. A new error code for indicating estimated time to completion of request would be handy, but out of scope for this document.
Note that there is a denial of service (DoS) attack by clients on willing source KDCs: the clients can ask the KDCs to acquire cross-realm ITGTs for many target realms. Ideally the quality of service for the Kerberos authentication service (AS) with PKINIT (and/or other slow pre-authentication mechanisms) should be separate from that of the Kerberos TGS co-located with it, and the PKCROSS-capable TGS as well, so as to be able to throttle low-priority requests when under load.
KDCs processing PKINIT requests crossing realms MUST apply either or both of:
KDCs MUST reject PKINIT requests from clients of foreign realms whose certificates cannot be validated, unless the client request the anonymous principal name in the target's realm.
The combined Kerberos/PKIX/DNSSEC transit path MUST be represented in any tickets issued using PKCROSS (see below). As usual, each realm's KDCs in the mix can set the transit policy checked flag if a client's transit path is acceptable per the realm's KDCs' local policy.
Two validation mechanisms are available: all PKIX [RFC5280] validation methods, and DANE [RFC6698]. DANE validation records SHOULD be stapled onto the client certificates by the issuing kx509 CA; alternatively clients can staple DANE validation records onto their PKINIT requests using an authorization-data element, AD-PKINIT-CLIENT-DANE.
Additionally, when PKIX certificate validation is used, the trust path should be encoded in an AD-INITIAL-VERIFIED-CAS authorization data element, per-PKINIT.
The notional transit path for a ticket issued by a target realm's KDCs includes:
When using DANE for validation of the issuer's certificate the target SHOULD represent the transit path as hierarchical from the source realm's domain to the root domain, then direct from there to the target's realm.
The notional transit path for a given client principal MUST be encoded as usual, using the Kerberos X.500 and domain-style representations of PKIX issuer names and DNS domainnames as faithfully to the original as possible.
[CREF4]QUESTION: Do we need a 100% faithful representation of the transit path?
A KDC can acquire a TGT using PKCROSS whose session key then becomes the long-lived, persistent symmetric key for a cross-realm principal from the source realm to the target realm (“krbtgt/TARGET@SOURCE”).
To do this the KDC MUST set the USE-SESSION-KEY-AS-REALM-KEY KDCOptions flag (TBD) in its request for an ITGT from the target realm. As usual, the target realm's KDC MUST validate the client principal's certificate. The target realm's KDC MUST NOT return a TGS-REP until the new principal is committed to its principal database, and MUST set the endtime of the ITGT to the time at which the source realm may begin using the new symmetrically-keyed principal.
The source realm's KDC MUST commit the new principal to its principal database and MUST NOT begin using the new principal's long-term keys until the new principal is available to all KDCs for the source realm and the endtime of the ITGT passes.
Target KDCs SHOULD require manual pre-approval of such new cross-realm principals. In small, isolated environments a KDC MAY be configured to pre-approve all such new principals.
By default, source KDCs SHOULD NOT automatically request long-term keying of cross-realm principals.
The proposed PKCROSS protocol has several useful properties described below.
No more manual keying of cross-realm principals via exchanging passwords in-person on a telephone call (or similar).
Kerberos with commonplace symmetrically-keyed hierarchical cross-real trusts can scale to a large universe of realms, but only if there are top-level realms that are willing to pair-wise trust and “child” realms. Such top-level realms do not exist in practice, leading to an O(N^2) scaling problem for most two-label realms.
Leveraging a PKI, such as a PKIX PKI [RFC5280] or a DNSSEC PKI [RFC4033] removes the need for either top-level realms (which are not likely to ever be operated as commercial or even non-profit entities) or O(N^2) pair-wise cross-realm symmetric keying.
The cost of this is having to add PKI trust paths to Kerberos trust paths (though the resulting trust path length need not be much different than before).
This protocol protects the privacy of client principals vis-a-vis their home realms, when the clients use the client-driven PKCROSS protocol.
This feature is generally and naturally available in PKI, and as this protocol is based on a kerberized certification authority, this protocol inherits this privacy feature from PKI.
The realms visited by the client may, of course, inform the client's home realm, but in the event that they don't, the client does gain this small measure of privacy. Of course, the privacy-conscious client SHOULD attach an OCSP Response [RFC6960] to its PKINIT request, per [RFC4557].
Clients need not validate the certificate trust path of destination realms. When they do not, the services used through those destination realms are as good as anonymous authentication. If the client saves the root or intermediate or end entity certificates of the destination realms that it cannot or does not validate, then the client can check that on future occasions the destination realm's certificate has not changed, and it may warn the user if it has. This quite similar to how clients using the secure shell (SSH) protocol [RFC4251] handle server authentication, and is commonly known as “leap-of-faith” (LoF) or trust-on-first-use (TOFU). The result is pseudonymous authentication.
Destination services too may apply LoF/TOFU: by using the subjectPublicKey of the certificate in the ticket's AD-CLIENT-CERTIFICATE KDC-issued authorization-data as the client's name instead of validating the transit path of the client.
For non-LoF/TOFU uses the main security consideration for applications is that improved scalability for Kerberos realm traversal implies larger Kerberos universes, and the larger a universe of trust the more important it is to have useful and expressive local policy for evaluating the trustworthiness of any given transit path. Because in most applications local policy should be a component external to the application, there is no impact on APIs here. However, an implementation may wish to provide applications with interfaces for specifying policies, either named or by value.
For LoF/TOFU uses there is a critical requirement that APIs not permit accidental aliasing of principal names as a result of LoF/TOFU being used. The simplest way to do this is to use a fingerprint of the peer principal's public key as their principal, and/or a fingerprint of the peer principal's realm's public key as their realm.
There are no GSS-API-specific considerations. The naming considerations described in Section 4.1 and the naming attributes defined in [I-D.williams-kitten-generic-naming-attributes] are sufficient. Note however that information about how PKCROSS was used to establish symmetrically-keyed cross-realm principals is lost and will not appear in the transit path in tickets issued by KDCs reached via such cross-realm principals.
If there is no acceptable or verifiable trust path for validating a peer's principal's and/or realm's certificate, then the local end-point MUST locally output the peer's principal (or realm) name as a fingerprint of one of:
The choice of which of the above to fingerprint is a local choice. The default SHOULD be (1). (2) allows for key rollover.
The fingerprints MUST be computed as follows:
For example, “:spk:MjNhNjM0YTM4NDFiZDdhNjVkODQ5YTdi”@FOO.EXAMPLE or “HTTP/someserver.foo.example@spkMmE1M2RiMjc1Nzk5ODFjNWQwYjk0OTAw”. Note that all such realm names have no period character ('.') in them and will too long to match top-level domainnames in use in the DNS, and no such principal names have a forward slash ('/') character in them. Note also that interpretation of such principal names as usernames on POSIX systems will either produce an empty string (due to implementation issues regarding the use of colons (':' as separators in POSIX user databases) or the full string, either way not likely ti collide with valid usernames.
We add a new GSS-API name-type: GSS_C_NT_PSEUDONYMOUS. This represents principals whose names are pseudonymous.
At this time pseudonymous principal names should not appear in Kerberos PDUs, thus no name-type need be assigned. If a pseudonymous name must be appear in a Kerberos PDU for any reason then the NT-UNKNOWN name-type should be used.
Scaling up the universe of realms reachable via any trust path necessarily dilutes trust overall, but not for specific paths. On the other hand, by shortening transit path lengths trust can be improved, though some short transit paths will have been symmetrically keyed using this PKCROSS protocol and therefore will be longer than they appear to be. These are subjective notions of trust, of course.
Once a cross-realm principal is symmetrically keyed the transit path used to automatically key that principal will no longer appear in subsequent cross-realm tickets issued by the target.
The Kerberos transit path encodes only realm names (including X.500-style names, thus PKIX certificate subject and issuer names), and lacks any public key information that might be useful for pinning. However, the certificate validation path for each realm in a transit path SHOULD be included in the transit path.
LoF/TOFU has additional security considerations. To start there is the obvious susceptibility to peer impersonation / man-in-the-middle (MITM) attacks on initial contact, which is mitigated by the attacker's need to always remain in the middle in order to avoid detection.
LoF/TOFU require the ability to remember peers' pseudonymous identities -- their public keys (or certificates), otherwise one remains vulnerable to peer impersonation / MITM attacks at all times. This requires synchronization of peer pseudonym databases across multiple devices (where users have multiple devices), which may not always be possible or performed.
It is critical that existing applications not be broken by the ability to use LoF/TOFU in new Kerberos implementations when those applications are re-linked with newer Kerberos implementations. To ensure this we require the use of public key fingerprints as principal and/or realm names; local mappings of learned pseudonym mappings onto semantically meaningful names are permitted where the user can validate the mapping. But keep in mind that most users never actually do much to verify peers' public keys in any application/protocol that provides LoF/TOFU [references for this would be nice -Nico].
See Section 3.4.1 for additional requirements for LoF/TOFU authentication.
There are no standard ways to express authorization policies for trust transit paths for either Kerberos nor PKI. A standard language for this would be extremely useful. Such a language should allow for the expression of policies for both, clients and services. Such a language should allow for the expression of complex realm/domain/other naming, and should allow for HSTS-style pinning [add references -Nico]. Such a language should allow for multiple paths where desired, and should allow for more than path rejection: it should also allow for reducing the entitlements assigned to a peer/realm for authorization purposes.
The need for a standard transit path policy expression language is not new, and such a language is broadly and generally needed. Therefore such a language is outside this document's scope.
Although the author arrived at this “kx509 + PKINIT == PKCROSS” idea independently, it is not an original idea. Henry Hotz and Jeffrey Altman each conceived the same idea years earlier. It is a relatively obvious idea when taking into account efforts to bridge disparate security mechanisms and credentials infrastructures.
| [RFC4033] | Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. |
| [RFC4251] | Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. |
| [RFC6960] | Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013. |