Internet DRAFT - draft-vanrein-kitten-krb-pseudonymity
draft-vanrein-kitten-krb-pseudonymity
Network Working Group R. Van Rein
Internet-Draft ARPA2.net
Intended status: Standards Track April 22, 2016
Expires: October 24, 2016
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.
Van Rein Expires October 24, 2016 [Page 1]
Internet-Draft Kerberos Pseudonymity Support April 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Principles and Definitions . . . . . . . . . . . . . . . . . 3
3. Procedures and Requirements . . . . . . . . . . . . . . . . . 4
4. Efficiency Considerations . . . . . . . . . . . . . . . . . . 6
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Van Rein Expires October 24, 2016 [Page 2]
Internet-Draft Kerberos Pseudonymity Support April 2016
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
Van Rein Expires October 24, 2016 [Page 3]
Internet-Draft Kerberos Pseudonymity Support April 2016
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.
Van Rein Expires October 24, 2016 [Page 4]
Internet-Draft Kerberos Pseudonymity Support April 2016
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.
Van Rein Expires October 24, 2016 [Page 5]
Internet-Draft Kerberos Pseudonymity Support April 2016
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
Van Rein Expires October 24, 2016 [Page 6]
Internet-Draft Kerberos Pseudonymity Support April 2016
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
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
<http://www.rfc-editor.org/info/rfc6112>.
Author's Address
Rick van Rein
ARPA2.net
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires October 24, 2016 [Page 7]
