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

Larry Zhu
What you suggested definitely makes sense to me. We shall define one by
all means.


-----Original Message-----
From: Martin Rex [mailto:[hidden email]]
Sent: Wednesday, October 19, 2005 6:13 AM
To: Nicolas Williams
Cc: Liqiang(Larry) Zhu; [hidden email]; [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

Nicolas Williams wrote:
>
> Q:  How will old implementations handle principal names that are empty
>     sequences?

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

Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand

Using anonymous@anonymous as the printable representation would be bad
since is wouldn't allow the application to select the realm that is want to
use when contacting the server (client selection).

I'll try to explain what I mean with an example.

I trust the KDC for SU.SE to keep my anonymity, but not so sure about
KTH.SE. So when contacting a server in KTH.SE I want to do a cross realm
jump with a anonymous principal. But since I've both got inital credentials
for SU.SE and KTH.SE, I want to be able to tell the gss-api layer, "use my
SU.SE credential and be anonymous".

How about anonymous@anonymous when I don't care, and anonymous@REALM when I
don't ? This have namespace issues so I'm not so sure how much I like it.

Love


"Liqiang(Larry) Zhu" <[hidden email]> writes:

> What you suggested definitely makes sense to me. We shall define one by
> all means.
>
>
> -----Original Message-----
> From: Martin Rex [mailto:[hidden email]]
> Sent: Wednesday, October 19, 2005 6:13 AM
> To: Nicolas Williams
> Cc: Liqiang(Larry) Zhu; [hidden email]; [hidden email]
> Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
>
> Nicolas Williams wrote:
>>
>> Q:  How will old implementations handle principal names that are empty
>>     sequences?
>
> 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

attachment0 (487 bytes) Download Attachment
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 05:11:04PM +0200, Love H?rnquist ?strand wrote:

>
> Using anonymous@anonymous as the printable representation would be bad
> since is wouldn't allow the application to select the realm that is want to
> use when contacting the server (client selection).
>
> I'll try to explain what I mean with an example.
>
> I trust the KDC for SU.SE to keep my anonymity, but not so sure about
> KTH.SE. So when contacting a server in KTH.SE I want to do a cross realm
> jump with a anonymous principal. But since I've both got inital credentials
> for SU.SE and KTH.SE, I want to be able to tell the gss-api layer, "use my
> SU.SE credential and be anonymous".
>
> How about anonymous@anonymous when I don't care, and anonymous@REALM when I
> don't ? This have namespace issues so I'm not so sure how much I like it.

Sure, and it sounds like a job for the GSS naming extensions if you want
to go further than that.

I still think the cname should not be an empty SEQUENCE of components,
instead the client should use an authorization-data element.

With Ticket extensions we could even ask that the KDC "allocate" a
unique anon name and tell the client, or maybe we could do that now with
pre-auth.

Anyways, I know I don't like the empty SEQUENCE of components.

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 Love Hörnquist Åstrand
Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
Allow me to clarify the I-D a bit:
 
in order to request anonymous service at the GSS-API level, you need present both of the following two things:
 
1) your credentials, this includes which realm you intend to contact.
 
2) your intention to request anonymous service. Implementation wise, I would use SSPI as an example, in addition to your username, realm name, password/smartcard/other-credentials, you should also supply a flag to request anonymous tickets, it is very similar to the way how you request  not to have the PAC in your tickets today.
 
In other words, selecting which credentials to use and requesting anonymous service are orthogonal, and should be treated as such. But note you need valid credentials in all cases.
 
in your example, you seemed to attempt to overload the user name in order to request anonymous tickets. this is not what I intended and it does not work. if you want to request an anonymous TGT from realm SU.SE, you can pick your account in SU.SE.
 
If you pick your credentials in SU.SE, then in order to go to realm KTH.SE,
you have to do cross-realm authentication. You can not pick your account at SU.SE and try to contact KTH.SE, if you do that, you could reveal your identify to KTH.SE, but I can not think a reason why you would want to request an initial TGT using the credential from SU.SE. Do we need to clarify this a bit and make sure implementations would make such mistakes?
 
perhaps we should add details how to implement this extension in GSS-API/SSPI, since most of questions so far are related to GSS-API/SSPI.
 
however, shall we have a separate I-D, or just add such details to this I-D? what is your opinion?
 

 

From: Love Hörnquist Åstrand [mailto:[hidden email]]
Sent: Fri 10/21/2005 8:11 AM
To: Liqiang(Larry) Zhu
Cc: [hidden email]; Nicolas Williams; [hidden email]; [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt


Using anonymous@anonymous as the printable representation would be bad
since is wouldn't allow the application to select the realm that is want to
use when contacting the server (client selection).

I'll try to explain what I mean with an example.

I trust the KDC for SU.SE to keep my anonymity, but not so sure about
KTH.SE. So when contacting a server in KTH.SE I want to do a cross realm
jump with a anonymous principal. But since I've both got inital credentials
for SU.SE and KTH.SE, I want to be able to tell the gss-api layer, "use my
SU.SE credential and be anonymous".

How about anonymous@anonymous when I don't care, and anonymous@REALM when I
don't ? This have namespace issues so I'm not so sure how much I like it.

Love


"Liqiang(Larry) Zhu" <[hidden email]> writes:


> What you suggested definitely makes sense to me. We shall define one by
> all means.
>
>
> -----Original Message-----
> From: Martin Rex [[hidden email]]
> Sent: Wednesday, October 19, 2005 6:13 AM
> To: Nicolas Williams
> Cc: Liqiang(Larry) Zhu; [hidden email]; [hidden email]
> Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
>
> Nicolas Williams wrote:
>>
>> Q:  How will old implementations handle principal names that are empty
>>     sequences?
>
> 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

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 Nicolas Williams
Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
"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.
 


From: Nicolas Williams [mailto:[hidden email]]
Sent: Fri 10/21/2005 11:05 AM
To: Love H?rnquist ?strand
Cc: Liqiang(Larry) Zhu; [hidden email]; [hidden email]; [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

On Fri, Oct 21, 2005 at 05:11:04PM +0200, Love H?rnquist ?strand wrote:


>
> Using anonymous@anonymous as the printable representation would be bad
> since is wouldn't allow the application to select the realm that is want to
> use when contacting the server (client selection).
>
> I'll try to explain what I mean with an example.
>
> I trust the KDC for SU.SE to keep my anonymity, but not so sure about
> KTH.SE. So when contacting a server in KTH.SE I want to do a cross realm
> jump with a anonymous principal. But since I've both got inital credentials
> for SU.SE and KTH.SE, I want to be able to tell the gss-api layer, "use my
> SU.SE credential and be anonymous".
>
> How about anonymous@anonymous when I don't care, and anonymous@REALM when I
> don't ? This have namespace issues so I'm not so sure how much I like it.

Sure, and it sounds like a job for the GSS naming extensions if you want
to go further than that.

I still think the cname should not be an empty SEQUENCE of components,
instead the client should use an authorization-data element.

With Ticket extensions we could even ask that the KDC "allocate" a
unique anon name and tell the client, or maybe we could do that now with
pre-auth.

Anyways, I know I don't like the empty SEQUENCE of components.

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

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


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

Larry Zhu
In reply to this post by Larry Zhu
We have double insurance in this I-D; the Anonymous ticket flag is
reserved, right?


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

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.

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
In reply to this post by Jeffrey Hutzelman
On Fri, Oct 21, 2005 at 03:18:37PM -0400, Jeffrey Hutzelman wrote:

> On Friday, October 21, 2005 02:12:47 PM -0500 Nicolas Williams 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.

Authorization-data.

Reply | Threaded
Open this post in threaded view
|

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

Tom Yu
In reply to this post by Jeffrey Hutzelman
>>>>> "jhutz" == Jeffrey Hutzelman <[hidden email]> writes:

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

>> Why not have an exceedingly-unlikely-to-have-been-used name?
>>
>> I worry about security bugs in older implementations.

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

There could be some ambiguity between the string representation of a
principal consisting of a sequence of zero members, and that of a
principal consisting of a sequence of one zero-lenght member.

Also, empty sequences as principal names _have_ been security
vulnerabilities for some implementations.

---Tom

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Nicolas Williams


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

> On Fri, Oct 21, 2005 at 03:18:37PM -0400, Jeffrey Hutzelman wrote:
>> On Friday, October 21, 2005 02:12:47 PM -0500 Nicolas Williams 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.
>
> Authorization-data.

That's not the same thing as a reserved principal name.  It doesn't fit in
all principal-name-slots, in Kerberos or in Kerberos-using protocols.

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Larry Zhu


On Friday, October 21, 2005 12:21:03 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> We have double insurance in this I-D; the Anonymous ticket flag is
> reserved, right?

No, I don't think so..  You seem to want to insure that application servers
which do not recognize anonymous tickets will always reject them.
Unfortunately, I don't think either of the approaches you have suggested
will accomplish that.

RFC4120 does not specify that the principal name consisting of zero
components (an empty sequence) is invalid; therefore you cannot assume that
implementations will not treat it as a valid principal name, possibly
represented in string form as the empty string.

RFC4120 does not require that application servers reject tickets containing
unknown ticket flags.  Unfortunately, it also fails to REQUIRE that they
ignore them, though it does require that behavior of clients.

One thing you can do, I think, is expect implementations to reject tickets
containing critical authorization data they don't understand...

-- Jeff

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
In reply to this post by Jeffrey Hutzelman
On Fri, Oct 21, 2005 at 03:41:49PM -0400, Jeffrey Hutzelman wrote:
> >>We do not appear to have left ourselves any mechanism for "reserved"
> >>principal names which appear in all realms, aside from the 'krbtgt' name.
> >
> >Authorization-data.
>
> That's not the same thing as a reserved principal name.  It doesn't fit in
> all principal-name-slots, in Kerberos or in Kerberos-using protocols.

But authz-data allow us to represent the desired semantic: that whatever
the name is, it's not meaningful for authorization.

Then the name could be anything, set by local convention, randomized
even.

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
There are different technical issues to address in GSS-API and
in the underlying Kerberos when dealing with anonymous principals.

At the GSS-API level, the use of an anonymous principal by
the initiator/client requires a software change of the initiator/client
software (to assert the "anonymous" flag when calling gss_init_sec_context).

GSS-API does not know or define "anonymous credentials", so the
(printable) name of the anonymous principal will rarely be used
by or relevant for the initator/client.
The printable name is relevant for the acceptor/server when performing
an authorization decision based on the name that pops up from
gss_accept_sec_context upon successful security context establishment.

A gssapi initiator must carefully check the resulting context
attributes from the initial call to gss_init_sec_context() when
requesting anonymity, because (as in the GSS-API tradition and
for backwards compatibility) anonymity is just another optional context
attribute.  It could be that the mechanism doesn't recognize
the attribute at all or that anonymity is not available for
some other reasons -- and in that case the initiator must NOT
send the initial security context token to the acceptor, because
it will likely reveal the initiators identity to the acceptor,
something that can rarely be "un-done".


-Martin

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:

>
> On Fri, Oct 21, 2005 at 03:41:49PM -0400, Jeffrey Hutzelman wrote:
> > >>We do not appear to have left ourselves any mechanism for "reserved"
> > >>principal names which appear in all realms, aside from the 'krbtgt' name.
> > >
> > >Authorization-data.
> >
> > That's not the same thing as a reserved principal name.  It doesn't fit in
> > all principal-name-slots, in Kerberos or in Kerberos-using protocols.
>
> But authz-data allow us to represent the desired semantic: that whatever
> the name is, it's not meaningful for authorization.
>
> Then the name could be anything, set by local convention, randomized
> even.

GSS-API v2 seems to have the necessary distinguishing hooks at its level
(which I forgot), it defines a special Nametype for the anonymous
principal, so that it can be used in a "portable" (=mechanism independent)
fashion, provided that the mechanism actually implements the necessary
logic.

The may be an issue for installed-base servers: do you want them to
get to see a principal name that they will hardly confuse with
any existing name, or do you prefer if they entirely abort the
authentication?

-Martin

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
In reply to this post by Martin Rex
On Fri, Oct 21, 2005 at 10:45:29PM +0200, Martin Rex wrote:
> There are different technical issues to address in GSS-API and
> in the underlying Kerberos when dealing with anonymous principals.

All very good and well, but we are discussing how clients/KDCs will
represented anonimity in KDC exchanges and in Tickets.  We can't even
get beyond that discussion!

> At the GSS-API level, the use of an anonymous principal by
> the initiator/client requires a software change of the initiator/client
> software (to assert the "anonymous" flag when calling gss_init_sec_context).
>
> GSS-API does not know or define "anonymous credentials", so the
> (printable) name of the anonymous principal will rarely be used
> by or relevant for the initator/client.

But it does define GSS_C_NT_ANONYMOUS and anonymous names, so it stands
to reason that credentials for anonymous names are anonymous
credentials.

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.

> The printable name is relevant for the acceptor/server when performing
> an authorization decision based on the name that pops up from
> gss_accept_sec_context upon successful security context establishment.

But GSS_Display_name() can indicate that the name is of
GSS_C_NT_ANONYMOUS type too, so the actual name may not be so important.

> A gssapi initiator must carefully check the resulting context
> attributes from the initial call to gss_init_sec_context() when
> requesting anonymity, because (as in the GSS-API tradition and
> for backwards compatibility) anonymity is just another optional context
> attribute.  It could be that the mechanism doesn't recognize
> the attribute at all or that anonymity is not available for
> some other reasons -- and in that case the initiator must NOT
> send the initial security context token to the acceptor, because
> it will likely reveal the initiators identity to the acceptor,
> something that can rarely be "un-done".

Shouldn't the initiator have to check on every call to
GSS_Init_sec_context() though?  What if the given mech's first context
token never reveals the initator identity but subsequent context tokens
may?

Nico
--

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
In reply to this post by Martin Rex
On Fri, Oct 21, 2005 at 10:54:45PM +0200, Martin Rex wrote:

> Nicolas Williams wrote:
> >
> > On Fri, Oct 21, 2005 at 03:41:49PM -0400, Jeffrey Hutzelman wrote:
> > > >>We do not appear to have left ourselves any mechanism for "reserved"
> > > >>principal names which appear in all realms, aside from the 'krbtgt' name.
> > > >
> > > >Authorization-data.
> > >
> > > That's not the same thing as a reserved principal name.  It doesn't fit in
> > > all principal-name-slots, in Kerberos or in Kerberos-using protocols.
> >
> > But authz-data allow us to represent the desired semantic: that whatever
> > the name is, it's not meaningful for authorization.
> >
> > Then the name could be anything, set by local convention, randomized
> > even.
>
> GSS-API v2 seems to have the necessary distinguishing hooks at its level
> (which I forgot), it defines a special Nametype for the anonymous
> principal, so that it can be used in a "portable" (=mechanism independent)
> fashion, provided that the mechanism actually implements the necessary
> logic.

Darn, I should have read this first :)  I just replied to your other
post to point out GSS_C_NT_ANONYMOUS...

> The may be an issue for installed-base servers: do you want them to
> get to see a principal name that they will hardly confuse with
> any existing name, or do you prefer if they entirely abort the
> authentication?

I say: let them see whatever you want them to see, possibly random
garbage (guaranteed by the KDC, say, never to have previously been
meaningful in that realm), provided that they also see a critical
indication of anonymity, that the name is not useful for authorization.

Nico
--

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman
In reply to this post by Martin Rex


On Friday, October 21, 2005 10:45:29 PM +0200 Martin Rex
<[hidden email]> wrote:

> A gssapi initiator must carefully check the resulting context
> attributes from the initial call to gss_init_sec_context() when
> requesting anonymity, because (as in the GSS-API tradition and
> for backwards compatibility) anonymity is just another optional context
> attribute.  It could be that the mechanism doesn't recognize
> the attribute at all or that anonymity is not available for
> some other reasons -- and in that case the initiator must NOT
> send the initial security context token to the acceptor, because
> it will likely reveal the initiators identity to the acceptor,
> something that can rarely be "un-done".

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?

(Maybe some of this belongs in kitten?)

-- Jeff

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 05:07:34PM -0400, Jeffrey Hutzelman wrote:

>
>
> On Friday, October 21, 2005 10:45:29 PM +0200 Martin Rex
> <[hidden email]> wrote:
>
> >A gssapi initiator must carefully check the resulting context
> >attributes from the initial call to gss_init_sec_context() when
> >requesting anonymity, because (as in the GSS-API tradition and
> >for backwards compatibility) anonymity is just another optional context
> >attribute.  It could be that the mechanism doesn't recognize
> >the attribute at all or that anonymity is not available for
> >some other reasons -- and in that case the initiator must NOT
> >send the initial security context token to the acceptor, because
> >it will likely reveal the initiators identity to the acceptor,
> >something that can rarely be "un-done".
>
> 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?

We might be able to do this now:

anon_name = GSS_Import_name(GSS_C_NT_ANONYMOUS, "anonymous" [or "garbage"]);
anon_cred = GSS_Acquire_cred(anon_name, {krb5});

And have the krb5 mech find any TGT it can and use it.  Or if you use
"anonymous@REALM" w/ GSS_C_NT_KRB5_ANONYMOUS then you could tell the
krb5 mech to use the first TGT it can find for a principal in that
realm.

> (Maybe some of this belongs in kitten?)

Maybe.  I've been thinking of a GSS_Acquire_cred_with_cred() function --
think of Kerberos<->PKI bridges.

Here we want to use an existing credential (a TGT) to acquire another
that does not reveal the identity normally authenticated by that
credential.

So,

    my_normal_cred = GSS_Acquire_cred(GSS_C_NO_NAME, {krb5});
    anon_name = GSS_Import_name(GSS_C_NT_ANONYMOUS, "anonymous" [or "garbage"]);
    anon_cred = GSS_Acquire_cred_with_cred(my_normal_cred, anon_name, {krb5});

This would be better, yes.

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:

>
> On Fri, Oct 21, 2005 at 10:45:29PM +0200, Martin Rex wrote:
> > At the GSS-API level, the use of an anonymous principal by
> > the initiator/client requires a software change of the initiator/client
> > software (to assert the "anonymous" flag when calling gss_init_sec_context).
> >
> > GSS-API does not know or define "anonymous credentials", so the
> > (printable) name of the anonymous principal will rarely be used
> > by or relevant for the initator/client.
>
> But it does define GSS_C_NT_ANONYMOUS and anonymous names, so it stands
> to reason that credentials for anonymous names are anonymous
> credentials.

Not really.  Actually the existing GSS-API v2 spec defers the gory
details to the mechanism (spec).  What it does say is this (rfc2743, 1.2.5):

   In ordinary GSS-API usage, a context initiator's identity is made
   available to the context acceptor as part of the context
   establishment process.  To provide for anonymity support, a facility
   (input anon_req_flag to GSS_Init_sec_context()) is provided through
   which context initiators may request that their identity not be
   provided to the context acceptor.  Mechanisms are not required to
   honor this request, but a caller will be informed (via returned
   anon_state indicator from GSS_Init_sec_context()) whether or not the
   request is honored. Note that authentication as the anonymous
   principal does not necessarily imply that credentials are not
   required in order to establish a context.


So the requirement is the use of the input anon_req_flag.
A fallback to regular authentication could be a problem if
an application tried to acquire "anonymous" credentials.

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

Portable initiators are recommended to use **default** credentials
whenever possible, and request anonymity only through the
"input anon_req_flag" to gss_init_sec_context.


>
> > The printable name is relevant for the acceptor/server when performing
> > an authorization decision based on the name that pops up from
> > gss_accept_sec_context upon successful security context establishment.
>
> But GSS_Display_name() can indicate that the name is of
> GSS_C_NT_ANONYMOUS type too, so the actual name may not be so important.

The primary purpose of gss_display_name() is to create a printable
representation, and I assume that quite often the printable
representation will be written to the logfile and the acutal OID
completely ignored (because most humans don't recognize OIDs).

>
> > A gssapi initiator must carefully check the resulting context
> > attributes from the initial call to gss_init_sec_context() when
> > requesting anonymity, because (as in the GSS-API tradition and
> > for backwards compatibility) anonymity is just another optional context
> > attribute.  It could be that the mechanism doesn't recognize
> > the attribute at all or that anonymity is not available for
> > some other reasons -- and in that case the initiator must NOT
> > send the initial security context token to the acceptor, because
> > it will likely reveal the initiators identity to the acceptor,
> > something that can rarely be "un-done".
>
> Shouldn't the initiator have to check on every call to
> GSS_Init_sec_context() though?  What if the given mech's first context
> token never reveals the initator identity but subsequent context tokens
> may?

Ooops -- you are correct!
For multiple round-trip security context exchanges the determination
of whether anonymity can be provided may not be possible on the
initial call to gss_init_sec_context().

So the rule will have to be that a mechanism (that supports anonymity)
must indicate the GSS_C_ANON_FLAG on every return from gss_init_sec_context
for as long as it tries to achieve it and there is still hope this
succeeds, and it must clear the flag as soon as it creates a token
that would reveal the initiators identity, so that the initiator
can realize it and abort without sending that particular context
token.



-Martin

123