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

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Martin Rex
Jeffrey Hutzelman wrote:
>
> This has always been something of a concern to me, more so now that we are
> contemplating adding anonymous authentication support to Kerberos.  In
> order to protect is anonymity, a client pretty much has to do what you
> describe; the problem is that the context is not yet fully established, and
> so the attributes might not be valid.  For example, it's not reasonable to
> assume that a context will not support integrity just because it doesn't
> have that attribute after the first call; why is that OK for anonymous?

Try to look at it from a different perspective:
The flags need to be valid as soon as they become relevant for
an application decision.

Prior to PROT_READY the integrity flag was relevant only for the
final call, because that was the first time that an application
would use message protection service.

With the addition of PROT_READY, the message integrity and confidentiality
flag must become valid whenever PROT_READY becomes valid--and when
PROT_READY is not available or applicable, this is again the
final call if it succeeds.

>
> (Maybe some of this belongs in kitten?)

Maybe we should migrate the thread?

-Martin

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
On Fri, Oct 21, 2005 at 11:54:55PM +0200, Martin Rex wrote:
> Jeffrey Hutzelman wrote:
> > (Maybe some of this belongs in kitten?)
>
> Maybe we should migrate the thread?

The GSS discussion should move to KITTEN, yes.

But we also have to hash out the Kerberos-specific issues.  How we
represent anonymous/unidentified principals in Ticket seems quite
independent of how this feature might be used in the context of the
GSS-API.  That discussion should stay here, at least until we discover,
if we discover, that it's very closely related to the GSS issues.

Nico
--

Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Larry Zhu
I sincerely believe we should finish PKINIT first. I would like to urge
every one of you start to review PKINIT-29 right away.

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[hidden email]]
Sent: Friday, October 21, 2005 2:58 PM
To: Martin Rex
Cc: Jeffrey Hutzelman; Liqiang(Larry) Zhu; [hidden email];
[hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

On Fri, Oct 21, 2005 at 11:54:55PM +0200, Martin Rex wrote:
> Jeffrey Hutzelman wrote:
> > (Maybe some of this belongs in kitten?)
>
> Maybe we should migrate the thread?

The GSS discussion should move to KITTEN, yes.

But we also have to hash out the Kerberos-specific issues.  How we
represent anonymous/unidentified principals in Ticket seems quite
independent of how this feature might be used in the context of the
GSS-API.  That discussion should stay here, at least until we discover,
if we discover, that it's very closely related to the GSS issues.

Nico
--

Reply | Threaded
Open this post in threaded view
|

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

Martin Rex
In reply to this post by Nicolas Williams
Nicolas Williams wrote:
>
> But it does define GSS_C_NT_ANONYMOUS and anonymous names, so it stands
> to reason that credentials for anonymous names are anonymous
> credentials.

I do not agree.

>
> In this case, of course, the credentials aren't "anonymous" -- the TGT
> presumably bears the user's principal name.  Instead the initiator
> should use the anon flag (GSS_C_ANON_FLAG).
>
> But I could see a mechanism with no authenticated initiator, acceptor or
> either (e.g., SPKM-3 is supposed to allow for unauthenticated/
> unidentified initiators).  And how would an application acquire a
> credential for such a mechanism?  I figure: use GSS_C_NT_ANONYMOUS.

Although nothing prevents a gssapi mechanism to implement that
and nothing prevents applications to request that,
portable applications will NOT normally do this, and IMHO
this model is too complex for my taste.

First issue: what is a credential?
IMHO, a credential is (secret) information that enables you
to authenticate yourself to others, and it often includes
(secret or public, but trusted) information that enables
you to authenticate others.

Think of SSL:
An SSL credential is normally an RSA-keypair plus a list
of trust anchors that enables you to authenticate your peers.

Nowadays anonymous SSL clients are the norm (as far as the
authentication at the SSL level is concerned), and Browsers
with SSL client certs are the exception.  But even with
an SSL client cert installed and when talking to a Web-Server
that requests SSL client certs and has announced that
he trusts the CA which signed our SSL client cert, most
Browsers offer the possibility for the user to decline
the use of the SSL client cert.  However you still want/need
the list of trust anchors to verify the Servers identity
(in most cases).


Whether you can just skip the initiator-to-server authentication
in a PKI-based protocol just as in the SSL case, or whether
you need to invent anonymous tickets (on the fly and under the covers)
for a Kerberos based gssapi mechanism depends on each
individual mechanisms.

Whether you use anonymous TGTs or just anonymous service tickets,
and whether you trust one KDC but not the other to live up to your
anonymity requirements is also an implementation detail -- as
far as portable GSS-API based applications are concerned.

If have special requirements for your management of anonymous
credentials, try to steer it through your mechanism-specific
credential management tool(s).  PLEASE do NOT put the burden to
make such distinctions on the (portable) GSS-API based applications
and do not expect them to mess around with credentials management
calls in fancy ways.

-Martin

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
On Sat, Oct 22, 2005 at 12:13:01AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> First issue: what is a credential?
> IMHO, a credential is (secret) information that enables you
> to authenticate yourself to others, and it often includes
> (secret or public, but trusted) information that enables
> you to authenticate others.

Such as an ephemeral Diffie-Hellman exponent.  Good enough for
unauthenticated key exchange.

Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Larry Zhu
I do not pretend I understand what is the threat you described below,
but if we just consider older implementations and make sure they do not
blindly accept the anonymous tickets thus resulting in a security
weakness, then I am positive that there are more implementations out
there today that will just ignore the critical authorization data in the
ticket than that of accepting the empty sequence in the client name, and
it is fairly clear to me that there are more 1510 implementations, than
that of 4120.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey
Hutzelman
Sent: Friday, October 21, 2005 12:19 PM
To: Nicolas Williams; Liqiang(Larry) Zhu
Cc: Love H?rnquist ?strand; [hidden email]; [hidden email];
Jeffrey Hutzelman
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt



On Friday, October 21, 2005 02:12:47 PM -0500 Nicolas Williams
<[hidden email]> wrote:

> On Fri, Oct 21, 2005 at 12:04:50PM -0700, Liqiang(Larry) Zhu wrote:
>> "empty SEQUENCE" is the only thing I believe we can count on that
>> older implementations will always fail if they do not support
>> anonymity as defined in this I-D.
>
> Why not have an exceedingly-unlikely-to-have-been-used name?
>
> I worry about security bugs in older implementations.

So do I.  Imagine an older implementation which renders the empty
sequence
as the empty string (an entirely reasonable thing to do).  Now, what
happens if the proposed anonymous principal is passed to krb5_kuserok,
and
the .k5login file contains an empty line?  Or maybe even a comment?

We do not appear to have left ourselves any mechanism for "reserved"
principal names which appear in all realms, aside from the 'krbtgt'
name.

-- Jeff

Reply | Threaded
Open this post in threaded view
|

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

Aaron D. Jaggard
In reply to this post by Jeffrey Hutzelman
 Dear all,

The anon-00 draft mentions that the client should ensure that a ticket
 is actually anonymous before using it for anonymous communication.
This may be difficult if the ticket isn't strongly bound to the
encrypted part of the KDC's reply.

While we do not believe the inclusion of anonymous tickets prevents
basic authentication goals from being met, they may lead to curious
behavior.  In one example, sketched below, the client may incorrectly
believe that her name has not yet been revealed to the server (because
she incorrectly believes that the server has opened an anonymous
ticket and not a second, non-anonymous ticket), when in fact the
server has seen the client's name.

In particular (see Sec. 7.2 on p. 28 of
ftp://ftp.cis.upenn.edu/pub/papers/scedrov/ms-cis-04-04.pdf for more
details): a client could request two tickets from a TGS, one anonymous
and one regular.  An attacker interchanges these two tickets so that
the client is mistaken about which one is anonymous. The client then
sends two requests, one using each ticket, without requesting mutual
authentication from the server.  The attacker may replace the
authenticator that does not name the client with a copy of the
authenticator that does name the client.  As a result, the server will
be able to open both tickets but only one of the authenticators. The
server will then reply with an error message that does not name the
client, but which the attacker may modify so that it does name the
client.

As a result, the client would incorrectly believe that her name has
not yet been seen the server.  (Of course, this particular scenario
depends on the client wanting to interact with a server both
anonymously and non-anonymously.  However, it illustrates that curious
behavior is possible with respect to beliefs about anonymity.)

Best regards,

Fred Butler, Iliano Cervesato, Aaron Jaggard, and Andre Scedrov
Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
In reply to this post by Larry Zhu
If the two tickets get swapped, it will be detected when AP_REQ is
verified when the ticket is used, but at that point, the client's
identity is revealed.

Hence at this point I believe this issue is specific to anonymity
support.
-- Larry

-----Original Message-----
From: Aaron D. Jaggard [mailto:[hidden email]]
Sent: Monday, November 07, 2005 1:27 AM
To: Jeffrey Hutzelman; Liqiang(Larry) Zhu; [hidden email]
Cc: [hidden email]; Iliano Cervesato; [hidden email];
Andre Scedrov
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

 Dear all,

The anon-00 draft mentions that the client should ensure that a ticket
 is actually anonymous before using it for anonymous communication.
This may be difficult if the ticket isn't strongly bound to the
encrypted part of the KDC's reply.

While we do not believe the inclusion of anonymous tickets prevents
basic authentication goals from being met, they may lead to curious
behavior.  In one example, sketched below, the client may incorrectly
believe that her name has not yet been revealed to the server (because
she incorrectly believes that the server has opened an anonymous
ticket and not a second, non-anonymous ticket), when in fact the
server has seen the client's name.

In particular (see Sec. 7.2 on p. 28 of
ftp://ftp.cis.upenn.edu/pub/papers/scedrov/ms-cis-04-04.pdf for more
details): a client could request two tickets from a TGS, one anonymous
and one regular.  An attacker interchanges these two tickets so that
the client is mistaken about which one is anonymous. The client then
sends two requests, one using each ticket, without requesting mutual
authentication from the server.  The attacker may replace the
authenticator that does not name the client with a copy of the
authenticator that does name the client.  As a result, the server will
be able to open both tickets but only one of the authenticators. The
server will then reply with an error message that does not name the
client, but which the attacker may modify so that it does name the
client.

As a result, the client would incorrectly believe that her name has
not yet been seen the server.  (Of course, this particular scenario
depends on the client wanting to interact with a server both
anonymously and non-anonymously.  However, it illustrates that curious
behavior is possible with respect to beliefs about anonymity.)

Best regards,

Fred Butler, Iliano Cervesato, Aaron Jaggard, and Andre Scedrov
123