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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 18 Oct 2005 16:21:34 -0700

Answer: on page 5, section 4; 

  Interoperability and backward-compatibility notes: the KDC is given
   the task of rejecting a request for an anonymous ticket when the
   anonymous ticket is not acceptable by the server.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 4:16 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Oct 2005 10:52:05 -0500

>    anonymous ticket is not acceptable by the server.

I guess that'll do.  But it might be easier to just have the name be
something like "anonymous/anonymous/anonymous" :)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Oct 2005 12:19:14 -0400

> something like "anonymous/anonymous/anonymous" :)

Ew.

Perhaps it would be more appropriate for fully-anonymous tickets to use a 
special principal name designated for that purpose, which is well-formed so 
as not to break older implementations, but cannot conflict with a 
legitimate principal name in any realm.  This seems like an appropriate use 
of the "other" realm type, which would let us use a principal name like 
"anonymous@anonymous:"

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Oct 2005 11:24:56 -0500

> of the "other" realm type, which would let us use a principal name like 

Sure.

Also, the principal name could be arbitrary, with a critical
authorization-data type being used to indicate anonimity.

BTW, we've had this discussion before.  I recall asking about the
criticality of ticket flags because I wanted to have a flag that means
"anonymous" and, as I recall, Sam suggested the use of critical
authz-data instead.

I prefer the authz-data approach, actually, in light of RL Bob Morgan's
note.

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 19 Oct 2005 10:43:03 -0700

just to state the obvious,  the anonymous principal name and empty realm is the IN/MN, and can be mapped to anonymous@anonymous as the printable name, you can call GSS_Import_name() with anonymous@anonymous <mailto:anonymous@anonymous>  to work with this extension, if necessary.
 
 although the current draft does not talk about how to use this mechanism with GSS-API, we can add the details and the anonymous client can have a wellknown names at that level, I chose the anonymous client principal name because anonymous@anonymous is not reserved in Kerberos today.
 
I also have a few comments on the proposal of using critical authz data, the client need to verify the ticket is anonymous, so using this alone does not help the client. On the other hand, the use of empty client principal name is in spirit equivalent of using critical authz data, in the sense it can not be ignored by KDCs, at least I can not think of a reason why the KDCs can ignore these.

________________________________

From: [email-masked] on behalf of Nicolas Williams
Sent: Wed 10/19/2005 9:24 AM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

Sure.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Oct 2005 14:18:33 -0500

On Wed, Oct 19, 2005 at 10:43:03AM -0700, Liqiang(Larry) Zhu wrote:
> just to state the obvious,  the anonymous principal name and empty
> realm is the IN/MN, and can be mapped to anonymous@anonymous as the
> printable name, you can call GSS_Import_name() with
> anonymous@anonymous <mailto:anonymous@anonymous>  to work with this
> extension, if necessary.

Yes, this is obvious.

> I also have a few comments on the proposal of using critical authz
> data, the client need to verify the ticket is anonymous, so using this
> alone does not help the client. On the other hand, the use of empty
> client principal name is in spirit equivalent of using critical authz
> data, in the sense it can not be ignored by KDCs, at least I can not
> think of a reason why the KDCs can ignore these.

The client can't verify that the ticket is for anonymous -- the
cname/crealm are inside the Ticket after all, as is the authz-data.

The client just has to trust the KDC; that's how it is now, without
anonymous principals.

Nico
--