Subject: RE: Kerberos Anonymity Support

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 10:27:13 -0800

Martin Rex wrote:
> So one possibility to provide the service securely would be to ensure
at 
> the Kerberos protocol level that the KDC will NEVER EVER issue a
"normal" 
> ticket for that service.

This makes sense, 

Note that if the attacker can eavesdrop the conversation between the
client and the KDC, the client's identity is revealed to the attacker,
and the attacker can then reveal the client's identity to the server
(say send the server a message without a kerberos ticket), even when the
KDC NEVER issues a normal ticket for the specific service.

So perhaps we can settle this by having some text on this in the
security considerations section.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 10:17 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: Re: Kerberos Anonymity Support

Liqiang\ wrote:
> 
> My points are:
> 
> 1) If the attacker has a normal ticket, he can just send the normal 
> ticket to the server, and reveal the client's identity.
> 
> 2) say we come up with a solution to authenticate the plain text, and 
> the server can detect the fact that the ticket was swamped, but as 
> long as the normal ticket is sent to the server, the client's identity

> is revealed.
> 
> 3) the anonymous ticket and the normal ticket have different session 
> keys, the fact the ticket was swamped is always be detected.
> 
> Thus it seems to be me that it is NOT trackable to protect the client 
> identity, as long as the adversary gets hold of an normal ticket!

So one possibility to provide the service securely would be to ensure at
the Kerberos protocol level that the KDC will NEVER EVER issue a
"normal" ticket for that service.

If it doesn't exist, it can not be inserted by an attacker.

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 9 Mar 2006 18:04:34 -0800

Martin, please review -01 at
http://www.ietf.org/internet-drafts/draft-zhu-kerb-anon-01.txt.

I do not think I can incorporate "un-identifiablity within a group",
given vanilla Kerberos as defined in RFC4120 does not have the notion of
groups.  But I can envision vendors such as MS can easily build that
feature on top of the framework I laid out in -01.

Thx.

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 5:02 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Liqiang\ wrote:
> 
> Martin Rex wrote:
> > What I was proposing, indepent of any document, was another KDC 
> > flag/characteristic for a principal, similar to the "allowed for 
> > delegation" attribute which Microsoft uses.
> 
>  the KDC of the server/service got to make the decision, but the 
> decision maker should be the KDC of the client.
> 
> This model means that the client need to trust the KDC of the service.

Not necessarily.

Of course the client will have to trust some KDC, because the client can
not open and peek into the ticket to assure itself that it is an
anonymous ticket (a ticket identifying the anonymous principal).

(I'm not a Kerberos wizard, so you might need to transform my ideas  to
match reality.)

Would an "anonymous cross-realm ticket" address the issue that you do
not want to trust the KDC of the service?  (would that be a
(cross-realm) anonymous TGT?)

Dealing with "un-identifiable within a group" could be done similar to
anonymous.  create additional principals that identify such groups and
have them in the service tickets instead of ones own principal name.
Servers should be able to recognize (tell apart) anonymous or
group-anonymous tickets from regular tickets, is there room in the
tickets for such purposes?

The KDC could provide some control for which services such tickets can
be issued (i.e. services that will be able to handle them correctly).

-Martin