Pseudonymity Support for Kerberos
draft-vanrein-kitten-krb-pseudonymity-00

Abstract

Kerberos either retains client identity in all its ticket transformations, or it applies rigorous anonymity. When crossing over to another realm, an intermediate privacy measure is often desired, namely pseudonymity, as described in this specification.

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 April 12, 2016.

Copyright Notice

Copyright (c) 2015 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.

Table of Contents

• 1. Introduction
• 2. Principles and Definitions
• 3. Procedures and Requirements
• 4. Efficiency Considerations
• 5. Privacy Considerations
• 6. Security Considerations
• 7. IANA Considerations
• 8. Normative References
• Author's Address

1. Introduction

Kerberos' privacy model is not always well-suited for connections to other realms, especially when these are previously unencountered realms that have not earned the client's trust with respect to privacy. Normally, the client identity as obtained during an AS exchange is always retained by Kerberos. There is one exception, and that is anonymity [RFC6112], which completely conceals the client's principal name and possibly also its realm.

Where anonymity is obvious in concealing the client identity, this section describes a more covert alternative in the form of pseudonymity. By using a pseudonym, the ticket changes to another client identity, and the chosen identity may be selected specifically for dealing with a particular remote service. As a result, that remote can trace return visits without knowing what name is used locally, or when accessing other realms and/or services. As far as the remote realm is concerned, the pseudonym is just a client identity.

Pseudonyms can be useful to replace a personal login with that of a group or role, in which case a client can act on behalf of an entity for which it has established access rights. This is in the service of the remote realm, which is given a more concise view on the client than a mere personally identifying name. For instance, a remote realm may setup access rights to a group purchasing@EXAMPLE.COM and it is up to the administrators of EXAMPLE.COM which users are permitted to change their client identity to that account (or, informally, which users belong to the purchasing group). This separation of group management and access to the remote service is often a desirable distribution of responsibilities.

2. Principles and Definitions

Pseudonymity is applied during a TGS exchange. The client requests or permits the KDC to change its identity supplied in the TGT into another identity in the returned ticket. Without pseudonymity (or anonymity) the KDC simply copies this identity from the TGT to the returned ticket.

Clients can make implicit or explicit requests for a new client identity. An implicit request permits the KDC to apply whatever policies it has for a TGS, and an explicit request asks the KDC to set a particular client principal name. Explicit pseudonymity requests can be used with restrictive KDC policies, such as demanding a client identity to be selected from a set of possibilities.

The application of pseudonymity can be realm-neutral or realm-changing. Realm-neutral means that the realm of the TGT included in the TGS-REQ is the same as the client identity's realm. Realm-changing means that those realms differ. When applying pseudonymity, the client realm is replaced with the TGT realm, which only has an impact in the realm-changing case. It is not permitted to apply pseudonimity more than once in a realm-changing manner, to avoid arbitrary proxying between realms; a remote realm shall only welcome a client identity from its login realm and a client shall not accept arbitrary relaying of its identity to realms beyond the ones it uses directly. There is no limitation on realm-neutral pseudonymity, neither before nor after realm-changing pseudonymity.

To test whether a KDC is willing to support pseudonymity, the client may set the "pseudonymity" flag in the kdc-options field of its AS-REQ. When the KDC produces a ticket, it MAY respond to this KDC option by setting the "pseudonymity" ticket flag; if it does, it is a statement that the KDC is supportive of pseudonymity.

For explicit pseudonymity, the requested client principal name is included in the optional cname field of the TGS-REQ; this field is not normally included in this message, but may be used after assuring that the KDC supports pseudonyms. Explicit requests are unacceptable after applying realm-changing pseudonymity; this leaves room for a last realm-neutral change of the client identity just before crossing over to anoter realm, namely when a TGS-REQ returns a server referral.

3. Procedures and Requirements

A client MAY always send a TGS-REQ with a "pseudonymity" KDC option, even when there is no "pseudonymity" ticket flag. KDCs unsupportive of pseudonymity will silently ignore the unknown KDC option.

The KDC does not apply pseudonymity without "pseudonymity" KDC Options in the TGS-REQ; however, if psuedonymity is required by local policy, it MAY return a KRB-ERROR with code TODO

A number of rules MUST be applied by the KDC if it receives a TGS-REQ with the "pseudonymity" KDC option:

1. For explicit psuedonymity, the TGT must have the "pseudonymity" flag set; if not, it responds with KRB-ERROR code KDC_ERR_WRONG_REALM (because realm-changing pseudonymity appears to have been applied already).
2. For realm-changing pseudonymity, the TGT must have the "pseudonymity" flag set; otherwise, the request for pseudonymity is ignored if it is implicit, or leads to KDC_ERR_SVC_UNAVAILABLE if it is explicit.
3. The KDC may apply local policy; for implicit pseudonymity, it silently ignores disapproved requests; for explict pseudonymity, it responds to disapproved requests with KRB-ERROR code KDC_ERR_C_PRINCIPAL_UNKNOWN if it policy forbids the use of pseudonymity, or KDC_ERR_PRINCIPAL_NOT_UNIQUE (TODO:e-data) if it is permitted but lacks guidance on what to choose. The latter error message may also be generated if zero or one potential principals were found, but other things stop it, such as an explicit confirmation of setup by the end user through an external mechanism.
4. As a special case of the foregoing, external pseudonymity with the special name of type NT-UNKNOWN and zero components in the name string is permitted by default policy and cannot be setup with a pseudonym by the user, so it always triggers the aforementioned KDC_ERR_PRINCIPAL_NOT_UNIQUE error reply.
5. TODO: Define special error codes for pseudonymity; overloading existing ones isn't proper
6. When the KDC applies realm-changing pseudonymity, it MUST clear the "pseudonymity" flag in the returned ticket. This serves two purposes. First, it drops the knowledge of KDC-supported pseudonymity for the new realm. Second, it ensures that realm-changing pseudonymity is applied at most once. In all other cases, when the KDC returns a ticket it MUST copy the "pseudonymity" ticket flag from the TGT in the TGS-REQ.

Clients supportive of pseudonymity MUST ensure that the "pseudonymity" flag in a TGS-REP is never set unless the "pseudonymity" KDC option was set in the corresponding TGS-REQ.

Clients supportive of pseudonymity SHOULD process the "pseudonymity" flag in the TGS-REP. When it is set, the client identity in the TGS-REP may have changed, and give rise to somewhat different handling of the returned ticket. Those clients MUST also verify that the client identity is unchanged when the "pseudonymity" flag in the TGS-REP is not set.

Clients supportive of pseudonymity MUST notice realm-changing pseudonymity in a TGS-REP, and then ensure that the "pseudonymity" ticket flag is reset on the returned ticket; they MUST NOT accept realm-changing pseudonymity based on TGTs without "pseudonymity" ticket flag, and they MUST NOT request explicit pseudonymity based on TGTs without "pseudonymity" ticket flag. They MAY request realm-changing implicit pseudonymity based on TGTs without "pseudonymity" ticket flag, but this will be silently ignored by the KDC.

These specifications permit arbitrary rewrites of client principal names within the local realm to which the client signed up, either at the initiative of the client or the KDC. This means that a database of pseudonyms can be set up in the client and/or the KDC. The KDC is probably most useful when it applies pseudonymity during a request for a service ticket, and even more likely when it decides that realm crossover is involved in finding that ticket.

There are two situations in which the KDC explicitly lists pseudonyms that are acceptable for a request, as part of an error message KDC_ERR_PRINCIPAL_NOT_UNIQUE with an e-data field containing an ASN.1 SEQUENCE OF PrincipalName in DER encoding. TODO: encryption? This reply can be sent when the client needs it, to which end it sends an explicit pseudonymity request with a cname holding an NT-UNKNOWN name type. Alternatively, the KDC may generate this message when its policy requires pseudonymity but lacks policies to select one pseudonym; this requires that the "pseudonymity" KDC option is set in the TGS-REQ; it is especially of interest when the KDC is about to release a realm crossover ticket from the client's realm to a service realm. The e-data may hold an empty sequence to signal that no options exist; it may contain one or more PrincipalNames when it lacks the policy setup to make a choice.

Although it may seem unnatural to permit pseudonymity to foreign realms as well, it can actually be quite helpful. First, since it is always implicit pseudonymity, the remote KDC cannot create a "more unique" representation of the client identity; it is however able to group clients. Think of time-constrained test rides in public or free-trial accounts, or think of temporary gold or silver status access. This sort of use case enables the service to provide previews without demanding clients to setup accounts upfront. This provides a friendlier, and more useful way to explore new services. The service on the other hand, avoids a long list of one-time users that never return because they don't like the functionality on offer. With this in mind, it is recommended to continue to send the "pseudonymity" KDC option on any TGS-REQ to a remote realm, so long as the TGT has the "pseudonymity" flag set.

Note that foreign realms may hide information in the tickets that they return, but this is not likely to be very useful; tickets are not constantly updated during use, and they are discarded after a brief usage period. These properties makes them far less potent than other privacy alerts, such as browser cookies.

TODO: Use Anonymous Kerberos [RFC6112] as a checklist, for instance refer to it for its handling of AuthorizationData.

4. Efficiency Considerations

TODO:WRITE; lightweight mechanism, choice of central setup in KDC

5. Privacy Considerations

TODO:WRITE; pseudonym appears like the right person; identities tailored to targeted service; choice of decentral setup in client; remote realm cannot run away and make us move from realm to realm; remote realm can hardly store interesting information in the tickets

6. Security Considerations

TODO:WRITE; impersonation guarded by KDC (TODO: spec); remote realm might do this in hidden ticket info anyway, or may use another identity, which seems harmless?

7. IANA Considerations

TODO:WRITE; "pseudonymity" KDC option; "pseudonymity" ticket flag

8. Normative References

Author's Address