Subject: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 18 Oct 2005 14:58:10 -0700

I would like to bring this I-D to the attention of krb-wg. I would like
to request the working group to accept this I-D as a work item.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, October 18, 2005 12:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-zhu-kerb-anon-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Anonymity Support for Kerberos
	Author(s)	: L. Zhu, et al.
	Filename	: draft-zhu-kerb-anon-00.txt
	Pages		: 8
	Date		: 2005-10-18
	
   This document defines the use of anonymous Kerberos tickets for the
   purpose of authenticating the servers and enabling secure
   communication between a client and a server, without identifying the
   client to the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhu-kerb-anon-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of
the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zhu-kerb-anon-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zhu-kerb-anon-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 18 Oct 2005 19:13:15 -0400

> to request the working group to accept this I-D as a work item.

Note that I've placed an item on our agenda for Vancouver to discuss this 
draft, briefly.  The draft agenda is available on the IETF 64 meeting web 
site; please send any comments my way.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Oct 2005 18:15:47 -0500

> to request the working group to accept this I-D as a work item.

IIRC I proposed something much like this at an interim WG meeting in
Boston, several years ago.  I'm glad to see you put this forward and
think this should be a WG item.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Oct 2005 18:16:11 -0500

Q:  How will old implementations handle principal names that are empty
    sequences?

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 Oct 2005 21:16:10 -0400

In a prior life, I had the job of setting up a service by which end
users were able to authenticate to a third party in such a way that
the third party could authenticate them only as someone that is a member
of a particular authentication domain.   Given that this was a web
service, users would go to a web site, enter their username/password
over TLS and be issued a client certificate that could be used to
authenticate to the online database.  Now the important aspects here
was that the certificate had to contain no information that would
identity the client as anyone other a member of the approved domain.
So the DN contained random nonsense and the certificate was signed
by an approved CA.

A solution to this problem will be crucial to using Kerberos for a
variety of federated authentication problem spaces.  I would like to
see a solution to this included in this draft.  The difference would
be that a ticket would be issued with a realm name but no principal
and all of the transited checks would still apply.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Oct 2005 15:13:08 +0200 (MET DST)

> Q:  How will old implementations handle principal names that are empty

The use of an empty (zero-length) string for the printable representation
of the Kerberos principal name would be a problem, because it would
be an illegal parameter at the GSS-API level.

As has been suggested in the GSS-API long ago, a gssapi mechanism that
implements an anonymous principal should define a non-empty
printable representation for it.

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 19 Oct 2005 15:45:24 +0200

> printable representation for it.

Heimdal uses the string "anonymous" for the principal in the anonymous
implementation that we have (default off).

Love