Anonymous kerberos - Revision history

SamHartman: add pointers to pkinit configuration

2010-01-11T16:46:37Z

add pointers to pkinit configuration

SamHartman: add host registration

2010-01-04T20:15:00Z

add host registration

SamHartman: fix formatting

2010-01-04T20:09:42Z

fix formatting

SamHartman: document anonymous

2009-12-28T17:07:18Z

document anonymous

New page

'''Anonymous kerberos''' provides a mechanism for
[[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:

# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication
# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.

There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.

==Completely anonymous ==

In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm. Diffie-Hellman key exchange is used to establish a shared secret.. To use completely anonymous Kerberos:

# Configure the KDC to support pkinit, setting at least <t>pkinit_identity</t> on the KDC.
# Set <t>pkinit_anchors</t> so that the client can verify the KDC certificate
# Create the <t>WELLKNOWN/ANONYMOUS</t> principal in the realm to signal that fully anonymous Kerberos is enabled.

On the client use <t> kinit -n @REALM</t> or <t> kadmin -n
@REALM</t> to request anonymous tickets. In klist and in
service ACLs the resulting authentication will use the
<t>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</t> [[well known principal]].

== Realm Exposed Anonymous ==

Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm. The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.

On the client, use <t>kinit -n principal</t> to authenticate. A password or other credential will be required just as if the <t>-n</t> flag is not included. However, the resulting principal will be <t>WELLKNOWN/ANONYMOUS@REALM</t>.

== Implementation Status ==
xi
See [[Projects/Anonymous pkinit]] for implementation status.

@@ Line 11: / Line 11: @@
 In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm.  Diffie-Hellman key exchange is used to establish a shared secret..  To use completely anonymous Kerberos:
-# Configure the KDC to support pkinit, setting at least <tt>pkinit_identity</tt> on the KDC.
+# Configure the KDC to support [[Pkinit configuration |Pkinit]]
-# Set <tt>pkinit_anchors</tt> so that the client can verify the KDC certificate
+# Create the <tt>WELLKNOWN/ANONYMOUS</tt> principal in the realm to signal that fully anonymous Kerberos is enabled.  Use the command <pre> addprinc -randkey WELLKNOWN/ANONYMOUS</pre> in <b>kadmin</b> to accomplish this.
 On the client use <tt> kinit -n @<i>REALM</i></tt> or <tt> kadmin -n
@@ Line 29: / Line 29: @@
 One common use case for anonymous Kerberos is to permit any user to register a host in a realm even if they don't have a Kerberos identity.  That way, these automated installation systems can register a host for Kerberos so that Kerberos services can be established.  To permit this use case, configure fully anonymous Kerberos as described above.  Then, add the following entry to <tt>kadm5.acl</tt>
 <pre>
-WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS a host/*@YOUR_REALM Status ==
+WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS a host/*@YOUR_REALm
 </pre>

← Older revision		Revision as of 20:15, 4 January 2010
Line 26:		Line 26:
	On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate. A password or other credential will be required just as if the <tt>-n</tt> flag is not included. However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.		On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate. A password or other credential will be required just as if the <tt>-n</tt> flag is not included. However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.

⚫	== Implementation ~~Status~~ ==
		+	== Host registration ==
		+
		+	One common use case for anonymous Kerberos is to permit any user to register a host in a realm even if they don't have a Kerberos identity. That way, these automated installation systems can register a host for Kerberos so that Kerberos services can be established. To permit this use case, configure fully anonymous Kerberos as described above. Then, add the following entry to <tt>kadm5.acl</tt>
		+	<pre>
		+	WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS a host/*@YOUR_REALM Status ==
		+	</pre>
		+
		⚫	== Implementation status ==

	See [[Projects/Anonymous pkinit]] for implementation status.		See [[Projects/Anonymous pkinit]] for implementation status.

@@ Line 2: / Line 2: @@
 [[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:
- # Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication
+# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication
- # Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.
+# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.
 There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.
@@ Line 11: / Line 11: @@
 In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm.  Diffie-Hellman key exchange is used to establish a shared secret..  To use completely anonymous Kerberos:
- # Configure the KDC to support pkinit, setting at least <t>pkinit_identity</t> on the KDC.
+# Configure the KDC to support pkinit, setting at least <tt>pkinit_identity</tt> on the KDC.
- # Set <t>pkinit_anchors</t> so that the client can verify the KDC certificate
+# Set <tt>pkinit_anchors</tt> so that the client can verify the KDC certificate
- # Create the <t>WELLKNOWN/ANONYMOUS</t> principal in the realm to signal that fully anonymous Kerberos is enabled.
+# Create the <tt>WELLKNOWN/ANONYMOUS</tt> principal in the realm to signal that fully anonymous Kerberos is enabled.
-On the client use <t> kinit -n @<i>REALM</i></t> or <t> kadmin -n
+On the client use <tt> kinit -n @<i>REALM</i></tt> or <tt> kadmin -n
-@<i>REALM</i></t> to request anonymous tickets.  In klist and in
+@<i>REALM</i></tt> to request anonymous tickets.  In klist and in
 service ACLs the resulting authentication will use the
-<t>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</t> [[well known principal]].
+<tt>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</tt> [[well known principal]].
 == Realm Exposed Anonymous ==
@@ Line 24: / Line 24: @@
 Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm.  The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.
-On the client, use <t>kinit -n <i>principal</i></t> to authenticate.  A password or other credential will be required just as if the <t>-n</t> flag is not included.  However, the resulting principal will be <t>WELLKNOWN/ANONYMOUS@<i>REALM</i></t>.
+On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate.  A password or other credential will be required just as if the <tt>-n</tt> flag is not included.  However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.
 == Implementation Status ==
 See [[Projects/Anonymous pkinit]] for implementation status.