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

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 October 24, 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 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 specification describes a more covert alternative based on 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 realm. As a result, that remote realm can distinguish return visits without knowing what login name was used by the client, and what pseudonym it used when accessing other realms and/or services. As far as the remote realm is concerned, the pseudonym is just a client identity. As far as the client is concerned, the pseudonym may be specific for that one remote realm, or for a particular group of realms.

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 been authorised and for which the service has established access rights. This is in the interest of the remote realm, which is given a more concise view on the client than a mere personally identifying name of an individual client. For instance, a remote realm may authorise a client named purchasing@EXAMPLE.COM and it is up to the administrators of EXAMPLE.COM which of its individual users are permitted to change their client identity to that pseudonym (or, informally, which users belong to the purchasing group). This separate administration of group membership and authorisation is often a desirable distribution of responsibilities.

2. Principles and Definitions

TODO: Typical phases: (1) after AS, cliream==tgtrealm and ticket flag is set; KDC may change the realm to something local and may pull client along to stay in this state without clearing the ticket flag; (2) after realm crossover, clirealm!=tgtrealm and ticket flag set; skip this phase is ticket flag is reset; remote KDC may change cliname, will then also pull in clirealm but MUST clear the ticket flag; (3) clirealm==tgtream and ticket flag is cleared; client is user of remote realm; remote KDC may change cliname but not clirealm.

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 falls back to its default behaviour, which usually [RFC4120] means that it 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 prealm-changing seudonimity more than once, 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 restriction on realm-neutral pseudonymity, neither before nor after realm-changing pseudonymity.

TODO: Consider distinguishing local / foreign realm changes, and only constrain foreign realm changes to once. Local means that the TGT service realm and TGT client realm are the same while the ticket flag on the TGT is set. A local realm changes is permitted with or without clearing the ticket flag; foreign realm changes MUST clear the ticket flag and MUST move to the TGT service realm. This permits setting a realm to something spontaneous internally, such as john@EXAMPLE.COM to purchasing@PUBLIC.EXAMPLE.COM where the realm is a side-effect change of user john becoming group purchasing. Perhaps a better name for a foreign realm change is "pulling the client into a foreign realm", which may be done only once, and MUST therefore reset the ticket flag.

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.

To request that pseudonymity is applied by the KDC, a client can set the "pseudonymity" flag in a TGS-REQ.

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

TODO:PLACE: The server SHOULD welcome TGS exchanges that are only meant to change the client identity; these would request a service that matches the existing TGT, for instance the one originally obtained by the client, but possibly also aimed at another service realm.

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 MUST NOT apply pseudonymity without "pseudonymity" KDC Options in the TGS-REQ; however, if pseudonymity is required by local policy, it MAY return a KRB-ERROR with code TODO to indicate that the client should retry with the "pseudonymity" flag set.

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

1. For explicit pseudonymity, so when the cname field is included in the TGS-REQ, the TGT must have the "pseudonymity" flag set; if not, the KDC responds like a KDC without pseudonymity support.
2. For realm-changing pseudonymity, the TGT must have the "pseudonymity" flag set; otherwise, the KDC respondes like a KDC without pseudonymity support.
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 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 by the KDC 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. (TODO:WHY? 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 could 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, always at the initiative of the client, with a principal provided by the client 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, especially when it finds that realm crossover is involved in procuring 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 indicate that no options exist; it may contain one or more PrincipalNames when its policy is not sufficiently deterministic to make a choice.

Although it may seem unnatural to offer pseudonymity to foreign realms, 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 service. 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 profits from this mechanism by not accruing 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.

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

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.

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