Projects/Anonymous pkinit
The Anonymous Pkinit project is an implementation of anonymous pkinit from RFC 6112. This project allows users to obtain Kerberos tickets even if they have no principal registered in a realm. Use cases include hiding identity of a user for privacy, using FAST without registering a host, or automated registration of hosts.
Contents
Functional Requirements
anonymous tickets are tickets with a special well-known realm and principal name for the client principal. This principal will never appear in the service principal. The primary use case that motivates this project now is support for using anonymous tickets in host registration. That means that kadmin needs to support anonymous tickets and that kadmind needs to be able to ACL operations to anonymous principals.
The anonymous draft makes it optional whether KDCs are required to have certificates when anonymous pkinit is used. However if KDCs do not have certificates, authentication of KDCs becomes complicated. FAST permits an anonymous ticket corresponding to an unauthenticated KDC to be used in some circumstances. However authentication state needs to be maintained because some fast factors should not be used with an unauthenticated KDC. Most other uses of Kerberos are not appropriate with an anonymous KDC. So, implementing unauthenticated KDCs introduces significant code and policy complexity. It will not be included in this project but may be added in the future. Instead, for this project, we will implement support for anonymous clients using the traditional pkinit certificate verification rules.
The following is required:
- Administrative configuration to permit a realm to issue anonymous tickets
- API for requesting anonymous tickets
- Command line switches for kadmin and kinit
- GSS-API changes to support anonymous name type
Confirming Client and KDC Contribution
The anonymous draft requires that the client confirm that both the client and KDC contributed to the TGS session key. In draft 10 this is accomplished by including a KDC contribution key and confirming that the TGS session key is the combination of the KDC contribution key and the reply key. This mechanism has been implemented.
KDC Changes
Authorization data minimization
A new flag on authdata plugins is added to indicate that the plugin supports anonymous processing. This flag is only set on the plugin that copies TGT authorization data and the one that copies request authorization data. Other plugins are skipped in anonymous mode.
Session keys
The KDC chooses the session key before pre-authentication plugins are given a chance to run. A pre-authentication plugin can change the session key although if the session key has already been used this may cause trouble. The only case where a pre-authentication plugin is likely to use the session key is when generating authorization data to be included in an issued ticket. If a PAC or AD-KDC-ISSUED element is generated then it is likely that the session key will be used. However anonymous processing trims out authorization data so this is not an issue for anonymous. Also, the preauth framework on the KDC side runs plugins that may replace the reply key before other plugins so pkinit will always be the first preauth successful plugin when it succeeds.
The pkinit plugin generates a PA_PKINIT_KX padata item so that the client can confirm both parties contributed to the session key.
Enabling anonymous
If the WELLKNOWN/ANONYMOUS@REALM principal exists then anonymous authentication is supported. No special considerations are made to prohibit changing the password of this principal. As a result, it may be possible for an attacker to change the password of this principal and perform anonymous authentication without actually using pkinit.
Pkinit Changes
- Detect when anonymous is being used in the client and do not require key or sign the request
- KDC side: if anonymous tickets are requested don't require signed data to be signed
Library Changes
- Extend transited realm checking to deal with anonymous principals
- Add GIC support for obtaining anonymous principals if the anonymous principal is the client
A new API, krb5_get_init_creds_opt_set_anonymous is added to set the anonymous option. If this is turned on, then principals of the form @REALM are mapped to the wellknown principal in a realm. In addition, WELLKNOWN/ANONYMOUS@REALM is always treated as an anonymous authentication.
The canonicalization logic is expanded to permit any realm to be mapped to the anonymous realm when fully anonymous authentication is in use.
GSS-API Changes
- Display the anonymous principal name as GSS_NT_ANONYMOUS
- In this version GSS-API will be able to use existing anonymous credentials but will not be able to obtain credentials on its own. The main problem with obtaining credentials is selection of a realm to contact.
Kadmin Changes
- Add command line flag for requesting anonymous credentials
- ACL handling requires no changes
Review
This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type
- #~~~~
(hash mark followed by four tilde characters) on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.
Approvals
- TomYu 04:20, 16 February 2010 (UTC)
