Subject: Kerberos Anonymity Support

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 02:14:26 -0800

I am hoping to stir some discussion on the anonymity issue.

A suggested copy&paste attack is that the attacker can replace an
anonymous ticket with a normal ticket, and cause the client's identity
to be revealed.

If the attacker has the normal ticket, I would argue that the attacker
can send the ticket via covert channel to the server directly; the above
attack does not strike me as valuable from the adversary points, anybody
who has some thoughts on this lately?

Thanks,

-- larry

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Mar 2006 18:54:37 +0100 (MET)

> who has some thoughts on this lately?

I don't think that one should argue this way.

It is only an assumption, that there is no problem just because you
cannot see why this might be "valuable" to an attacker.

I think this assumption is flawed in two respects:
 (1) you probably have missed issues that
     (a) matter to others but not to you
     (b) you didn't think of so far
 (2) it is difficult to define "value to an attacker", because
     attackers may have all kinds of different motivations.
     some people have extremely weird motivations, and may
     consider certain action to be useful even if they loose their
     life in the process

It might be more appropriate to take a different approach:

 - is there any value in anonymity that justifies that we
   provide this feature at all?

 - if we see value in the availability of that feature,
   how can we provide it _securely_, i.e. in a fashion that makes
   it _extremely_ difficult (i.e. cryptographically difficult)
   for an attacker to subvert this characteristic (within the limits
   of the protocol).  We can not protect against client-side sniffing
   or auditing and publishing of the results at the protocol level.

It has been mentioned before -- there seem to be _different_ levels
of anonymity that would be beneficial for certain scenarios,
and it would be a good idea to address them seperately.

 - complete anonymity
 - un-identifiability within a clearly constrained group

 - others?

Regards,
-Martin

---

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

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!

> It has been mentioned before -- there seem to be _different_ levels of

> anonymity that would be beneficial for certain scenarios, and it would
be a good 
> idea to address them seperately.

> - un-identifiability within a clearly constrained group

I agree. I wanted to settle down on the ticket swamping attack first,
and figure out whether we should do something about it. My thinking
right now is no, what is your opinion?

Thx,

-- Larry

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

> can send the ticket via covert channel to the server directly; the 
> above attack does not strike me as valuable from the adversary points,

> anybody who has some thoughts on this lately?

It has been mentioned before -- there seem to be _different_ levels of
anonymity that would be beneficial for certain scenarios, and it would
be a good idea to address them seperately.

 - complete anonymity

 - others?

Regards,
-Martin

---

From: Chaskiel M Grundman <[email-masked]>
Date: Fri, 03 Mar 2006 13:20:56 -0500

> anonymous ticket with a normal ticket, and cause the client's identity

I haven't read any documents that may address the anonymity issue, but how 
would this attack work? is the session key in the anonymous ticket related 
to the session key of another ticket owned by the user? if not, then the 
authentication would fail and the presence of the normal ticket with the 
client's identity is meaningless (the attacker could insert any ticket, not 
just one owned by the same user, or even the string "my name is _____" in 
their pasted packet and it would mean just as much.

---

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

Chaskiel M Grundman wrote:
> I haven't read any documents that may address the anonymity issue, but
how would this attack work?

The attack is that the adversary replaces the anonymous ticket with a
normal ticket, the server decrypts the normal ticket, and then fails to
decrypt the authenticator, because the anonymous ticket and the normal
ticket has different sessions key, but it was argued this was an issue
because the client's identity was revealed to the server in this
process.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Friday, March 03, 2006 10:21 AM
To: krb-wg mailing list
Subject: Re: Kerberos Anonymity Support 

> to be revealed.

I haven't read any documents that may address the anonymity issue, but
how would this attack work? is the session key in the anonymous ticket
related to the session key of another ticket owned by the user? if not,
then the authentication would fail and the presence of the normal ticket
with the client's identity is meaningless (the attacker could insert any
ticket, not just one owned by the same user, or even the string "my name
is _____" in their pasted packet and it would mean just as much.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 12:36:35 -0600

On Fri, Mar 03, 2006 at 06:54:37PM +0100, Martin Rex wrote:
> [...]

Define a threat model and desired features.  Analyze the proposal from
that standpoint.

>    provide this feature at all?

I think so.  (I first proposed something like this at an interim meeting
some four years ago.)

>    or auditing and publishing of the results at the protocol level.

Decide on a threat model.  Once you have that you can analyze the
protocol.  This essentially amounts to saying that attacks that fall
outside the threat model are not an issue; if they turn out to be
consequential nonetheless then we'll have failed to define the threat
model properly, but separating the threat model and the analysis will
help us avoid such mistakes.

>  - un-identifiability within a clearly constrained group

Absolutely.  E.g., w/o PK the KDC just has to know the client's
identity, but services the KDC is willing to let the client be anonymous
to need not; throw in x-realm and only the client's realm's KDCs need to
know.  With PK the client could be made totally anonymous to the KDC and
all other services (ignoring such details as the client's IP address,
route between the client and KDC, etcetera).

>  - others?

 - Pseudonymity.

Nico
--

---

From: Chaskiel M Grundman <[email-masked]>
Date: Fri, 03 Mar 2006 13:38:17 -0500

> because the client's identity was revealed to the server in this

the identity of some client that has used the same service non-anonymously 
was revealed to the server. The server has no way to know if it is this 
client's actual identity or not. As such, I do not believe that the 
attacker has revealed anything of value to the server.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 12:41:08 -0600

> attacker has revealed anything of value to the server.

Exactly.  The only way the attacker can truly reveal the client's ID is
is if it knows the session keys for the clients anon and non-anon
tickets for that service (or its TGTs' session keys).  And if that is
so then you have much bigger problems.

I.e., this attack doesn't work provided normal Kerberos V assumptions.

Nico
--

---

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

Chaskiel M Grundman wrote:
> the identity of some client that has used the same service 
> non-anonymously was revealed to the server. The server has no way to 
> know if it is this client's > actual identity or not. As such, I do
not believe that 
> the attacker has revealed anything of value to the server.

Excellent point.

-- Larry 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Chaskiel M
Grundman
Sent: Friday, March 03, 2006 10:38 AM
To: krb-wg mailing list
Subject: RE: Kerberos Anonymity Support 

> because the client's identity was revealed to the server in this 

the identity of some client that has used the same service
non-anonymously was revealed to the server. The server has no way to
know if it is this client's actual identity or not. As such, I do not
believe that the attacker has revealed anything of value to the server.

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Mar 2006 21:11:24 +0100 (MET)

> because the client's identity was revealed to the server in this

Attack is on thing.

A simple implementation flaw in the client side Kerberos might cause
the client to use the wrong ticket if both are present, and nothing
will prevent the server to extract and log the clients identity
when processing the request.

What is worse: with a buggy client, the client will likely retrieve
the correct session key from the cache, and therefore it may not
even notice the bug is present.

This client bug alone would not compromise the users identity
if the KDC would never issue both, anonymous and regular
service tickets for a single service principal.

Just a thought...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 14:23:10 -0600

> service tickets for a single service principal.

Martin, we must make some assumptions.

For example:

 - local security at the clients and servers

 - that the attacker has not broken the base Kerberos V cryptographic
   framework
 - that the attacker has not broken the base Kerberos V protocol

 - that the attacker has not somehow obtained access to the clients'
   long-term keys/passwords
 - that the attacker has not somehow obtained access to the clients'
   tickets' session keys
 - that the attacker has not somehow obtained access to the servers'
   long-term keys/passwords

 - that neither clients nor servers habitually shoot their feet off
   (i.e., that they aren't buggy, at least not grossly so)

So normally we wouldn't concern ourselves with implementation bugs in
this kind of forum; obviously if there are non-obvious-but-common
implementation pitfalls then we want to at least note them, and if the
protocol design can be reasonably modified to make obviate some such
pitfalls then we should consider it.

Now, identity selection, that is, how a client picks an identity and
associated credentials in any given context, is not a simple matter, and
certainly subject to implementation bugs, as is practically every IETF
standards-track protocol, this is true.  The question I have is: if we
listed all the possible bugs we could imagine, would we finish?

In this forum I'd rather work on the protocol design and/or analysis.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Mar 2006 22:11:16 +0100 (MET)

> In this forum I'd rather work on the protocol design and/or analysis.

So it seems that you don't think anonymity to be a feature with
value, because you don't care when that feature accidentally breaks.

I disagree.

I really think, that if we want to offer support for anonymity,
that we take good care to provide it in a secure and sound fashion,
and that not-so-uncommon bugs will not easily ruin all our efforts.

As I already indicated, anonymity is quite difficult to achieve.
One precaution that we could provide is that when a service
accepts a ticket for anonymous it should be unable to open
"normal" tickets by having the KDC seperate those service principals
(well, maybe unless we're on Windows, where the default is to
 open tickets by brute force because the service doesn't know or
 care what aliases have been assigned to it...)

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Mar 2006 22:37:18 +0100 (MET)

Martin Rex wrote:
> 
> If we want to provide "anonymity", then the ultimate goal is
> not to reveal our identity, not even accidentally.  So I
> believe there is value in every additional safeguard that
> we can provide.

When requiring the KDC strictly seperate receipients of
anonymous and regular service tickets, then this would
prevent anonymous requests from (legacy) kerberized services
which do not accout for and special-case anonymous clients
so far.  Existing kerberized service could rely on the
fact that they can distinguish users that authenticate
via Kerberos.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 15:40:10 -0600

On Fri, Mar 03, 2006 at 10:27:56PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Wow.  What is an appropriate response to this non-sequitur?
> 
> If a client has a set of different credentials an due to a bug
> uses the wrong credentials to access a resource -- is that
> a vulnerability?

In the client, yes, in the protocol, no.  I've stated my view, and you
choose to cast it as me not caring about bugs -- this is silly!

> believe there is value in every additional safeguard that

Please describe changes you would propose to Larry's proposal that would
make client-side bugs like the ones you fear impossible.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Mar 2006 15:15:46 -0600

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Mar 2006 22:27:56 +0100 (MET)

Nope -- the architecture is designed to fail to the safe side.
If the inappropriately used credentials have sufficient
privileges, we might not even realize the bug.  If the inappropriately
used credentials do not provide sufficient privileges to perform
the operation, the request is rejected or the access denied.

We still may create a problem (because we may ring bells in
audit trails), but the security of the system is not at risk.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 4 Mar 2006 00:58:42 +0100 (MET)

> make client-side bugs like the ones you fear impossible.

Uhmm, err, I haven't read the document yet.

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.

If you have an attribute "this is a service principal for anonymous
access only" and have the KDC issue ONLY anonymous tickets for
this service principal, then that service will never be able to
get any identity information out of a ticket, because the KDC
will not issue any and the service will not be able to open
tickets for other services.

I see it as a feature to have this kind of power on the KDC,
and that neither client-side bugs nor attackers replacing
tickets (ignoring their motives) will be able to change this.

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 3 Mar 2006 16:21:34 -0800

> 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.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, March 03, 2006 3:59 PM
To: Nicolas Williams
Cc: [email-masked]; Liqiang(Larry) Zhu; [email-masked];
[email-masked]

Nicolas Williams wrote:
> 
> Please describe changes you would propose to Larry's proposal that 
> would make client-side bugs like the ones you fear impossible.

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.

If you have an attribute "this is a service principal for anonymous
access only" and have the KDC issue ONLY anonymous tickets for this
service principal, then that service will never be able to get any
identity information out of a ticket, because the KDC will not issue any
and the service will not be able to open tickets for other services.

I see it as a feature to have this kind of power on the KDC, and that
neither client-side bugs nor attackers replacing tickets (ignoring their
motives) will be able to change this.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 4 Mar 2006 03:29:19 -0600

> Uhmm, err, I haven't read the document yet.

!!

> attribute which Microsoft uses.

Let me see if I understand: after slanderously saying that I don't care
"when that feature accidentally breaks" you propose an option, NOT a
requirement that leaves this "accidental break" still feasible?

Not that I have anything against the option you propose[*], but I don't
see how it saves the client having to deal with multiple identities and
credentials.  In fact, I don't see how you can avoid the identity
selection problem generally.

But you could avoid making uncalled for and unnecessary inflammatory
remarks.

[*]  Yet.  I reserve the right to find this option not worthwhile after
     having thought about it.

Nico
--