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
|

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

Larry Zhu
I would like to bring this I-D to the attention of krb-wg. I would like
to request the working group to accept this I-D as a work item.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Tuesday, October 18, 2005 12:50 PM
To: [hidden email]
Subject: I-D ACTION:draft-zhu-kerb-anon-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title : Anonymity Support for Kerberos
        Author(s) : L. Zhu, et al.
        Filename : draft-zhu-kerb-anon-00.txt
        Pages : 8
        Date : 2005-10-18
       
   This document defines the use of anonymous Kerberos tickets for the
   purpose of authenticating the servers and enabling secure
   communication between a client and a server, without identifying the
   client to the server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhu-kerb-anon-00.txt

To remove yourself from the I-D Announcement list, send a message to
[hidden email] with the word unsubscribe in the body of
the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-zhu-kerb-anon-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [hidden email].
In the body type:
        "FILE /internet-drafts/draft-zhu-kerb-anon-00.txt".
       
NOTE: The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail
readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
               
               
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

ATT3605451.TXT (322 bytes) Download Attachment
draft-zhu-kerb-anon-00.URL (120 bytes) Download Attachment
ATT3605452.txt (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Tuesday, October 18, 2005 02:58:10 PM -0700 "Liqiang(Larry) Zhu"
<[hidden email]> wrote:

> I would like to bring this I-D to the attention of krb-wg. I would like
> to request the working group to accept this I-D as a work item.

Note that I've placed an item on our agenda for Vancouver to discuss this
draft, briefly.  The draft agenda is available on the IETF 64 meeting web
site; please send any comments my way.

-- 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 Larry Zhu
On Tue, Oct 18, 2005 at 02:58:10PM -0700, Liqiang(Larry) Zhu wrote:
> I would like to bring this I-D to the attention of krb-wg. I would like
> to request the working group to accept this I-D as a work item.

IIRC I proposed something much like this at an interim WG meeting in
Boston, several years ago.  I'm glad to see you put this forward and
think this should be a WG item.

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 Larry Zhu
Q:  How will old implementations handle principal names that are empty
    sequences?

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
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:[hidden email]]
Sent: Tuesday, October 18, 2005 4:16 PM
To: Liqiang(Larry) Zhu
Cc: [hidden email]; [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

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

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman
In reply to this post by Larry Zhu

In a prior life, I had the job of setting up a service by which end
users were able to authenticate to a third party in such a way that
the third party could authenticate them only as someone that is a member
of a particular authentication domain.   Given that this was a web
service, users would go to a web site, enter their username/password
over TLS and be issued a client certificate that could be used to
authenticate to the online database.  Now the important aspects here
was that the certificate had to contain no information that would
identity the client as anyone other a member of the approved domain.
So the DN contained random nonsense and the certificate was signed
by an approved CA.

A solution to this problem will be crucial to using Kerberos for a
variety of federated authentication problem spaces.  I would like to
see a solution to this included in this draft.  The difference would
be that a ticket would be issued with a realm name but no principal
and all of the transited checks would still apply.

Jeffrey Altman



smime.p7s (4K) Download Attachment
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
Humm, it is not truly anonymous if the ticket contains the
authentication path.

Just to throw out an idea here, perhaps such check whether the client
comes from an approved domain can be done on the trust boundary itself.

Good stuff, thanks for sharing.

-- Larry

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jeffrey Altman
Sent: Tuesday, October 18, 2005 6:16 PM
To: [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt


In a prior life, I had the job of setting up a service by which end
users were able to authenticate to a third party in such a way that
the third party could authenticate them only as someone that is a member
of a particular authentication domain.   Given that this was a web
service, users would go to a web site, enter their username/password
over TLS and be issued a client certificate that could be used to
authenticate to the online database.  Now the important aspects here
was that the certificate had to contain no information that would
identity the client as anyone other a member of the approved domain.
So the DN contained random nonsense and the certificate was signed
by an approved CA.

A solution to this problem will be crucial to using Kerberos for a
variety of federated authentication problem spaces.  I would like to
see a solution to this included in this draft.  The difference would
be that a ticket would be issued with a realm name but no principal
and all of the transited checks would still apply.

Jeffrey Altman

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman
Liqiang(Larry) Zhu wrote:

> Humm, it is not truly anonymous if the ticket contains the
> authentication path.

It anonymous in the sense that you can't tell who it is.  In the case of
a University or a company with tens of thousands of people, it may be
adequate just to know that the realm is ATHENA.MIT.EDU.  You can't
determine from the ticket which of the tens of thousands is using the
ticket.

The reason I had to implement the project was due to one of the many
privacy laws that apply to Universities.   A University cannot divulge
the identity of a student.  In some cases, we had students attending
the University that the University could not (due to security reasons)
admit that the student was even registered.  This level of privacy
protection is at a different level than that required to protect the
identity of a dissident in a country that does not accept the notion of
free speech.

What you are proposing is appropriate for the latter.  Unfortunately,
for most business purposes I do not see how any organization would be
willing to trust it in a federated environment.

As long as we are discussing privacy issues, one of the concerns that
has been at the forefront of my mind in recent months are privacy issues
in the workplace caused by the increased support for SPNEGO in web
browsers and servers.  I am concerned that the automatic use of the
default identity credentials are used to contact the local KDC in an
effort to obtain either service tickets or a referral for remote sites.
I fear that KDC logs can be used to access information leaked simply
by the generation of the request for a HTTP/www.prochoice.org@REALM
or HTTP/www.aids-survivors.org@REALM service ticket.  Asking for an
anonymous ticket does not help in this case because I am attempting
to hide information from my local KDC.

Just something more to think about...

Jeffrey Altman


smime.p7s (4K) Download Attachment
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:
>
> 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
In reply to this post by Jeffrey Altman

Jeffrey Altman <[hidden email]> writes:

> I fear that KDC logs can be used to access information leaked simply
> by the generation of the request for a HTTP/www.prochoice.org@REALM
> or HTTP/www.aids-survivors.org@REALM service ticket.  Asking for an
> anonymous ticket does not help in this case because I am attempting
> to hide information from my local KDC.
>
> Just something more to think about...

How can you trust the local KDC to issue you a truly anonymous TGT from the
point of the local KDC ? Maybe this is what you are saying, can't figure
that out.

Why even bother to support it ? (anonymous TGS is a diffrent thing)

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand
In reply to this post by Martin Rex

Martin Rex <[hidden email]> writes:

> 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.
Heimdal uses the string "anonymous" for the principal in the anonymous
implementation that we have (default off).

Love


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
In reply to this post by Larry Zhu
On Tue, Oct 18, 2005 at 04:21:34PM -0700, Liqiang(Larry) Zhu wrote:
> 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.

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

Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Hutzelman


On Wednesday, October 19, 2005 10:52:05 AM -0500 Nicolas Williams
<[hidden email]> wrote:

> On Tue, Oct 18, 2005 at 04:21:34PM -0700, Liqiang(Larry) Zhu wrote:
>> 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.
>
> I guess that'll do.  But it might be easier to just have the name be
> 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

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
On Wed, Oct 19, 2005 at 12:19:14PM -0400, Jeffrey Hutzelman wrote:

>
>
> On Wednesday, October 19, 2005 10:52:05 AM -0500 Nicolas Williams
> <[hidden email]> wrote:
>
> >On Tue, Oct 18, 2005 at 04:21:34PM -0700, Liqiang(Larry) Zhu wrote:
> >>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.
> >
> >I guess that'll do.  But it might be easier to just have the name be
> >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:"

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

Reply | Threaded
Open this post in threaded view
|

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

Larry Zhu
Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
just to state the obvious,  the anonymous principal name and empty realm is the IN/MN, and can be mapped to [hidden email] as the printable name, you can call GSS_Import_name() with [hidden email] 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 [hidden email] 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: [hidden email] on behalf of Nicolas Williams
Sent: Wed 10/19/2005 9:24 AM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; [hidden email]
Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt

On Wed, Oct 19, 2005 at 12:19:14PM -0400, Jeffrey Hutzelman wrote:


>
>
> On Wednesday, October 19, 2005 10:52:05 AM -0500 Nicolas Williams
> <[hidden email]> wrote:
>
> >On Tue, Oct 18, 2005 at 04:21:34PM -0700, Liqiang(Larry) Zhu wrote:
> >>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.
> >
> >I guess that'll do.  But it might be easier to just have the name be
> >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:"

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

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
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
--

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

The client needs to know if the KDC understands the request-anonymous
KDC option, for that reason we need to the anonymous ticket flag. This
is because RFC4120 compliant KDCs ignore unknown KDC options.


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

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

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
On Wed, Oct 19, 2005 at 02:02:00PM -0700, Liqiang(Larry) Zhu wrote:
>
> The client needs to know if the KDC understands the request-anonymous
> KDC option, for that reason we need to the anonymous ticket flag. This
> is because RFC4120 compliant KDCs ignore unknown KDC options.

That's what AD-MANDATORY-FOR-KDC is there for :)

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
Not in the initial AS_REQ.

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

On Wed, Oct 19, 2005 at 02:02:00PM -0700, Liqiang(Larry) Zhu wrote:
>
> The client needs to know if the KDC understands the request-anonymous
> KDC option, for that reason we need to the anonymous ticket flag. This
> is because RFC4120 compliant KDCs ignore unknown KDC options.

That's what AD-MANDATORY-FOR-KDC is there for :)

Reply | Threaded
Open this post in threaded view
|

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

Nicolas Williams
On Wed, Oct 19, 2005 at 02:18:31PM -0700, Liqiang(Larry) Zhu wrote:
> Not in the initial AS_REQ.

Where does RFC4120 say that?

> -----Original Message-----
> From: Nicolas Williams [mailto:[hidden email]]
> Sent: Wednesday, October 19, 2005 2:16 PM
> To: Liqiang(Larry) Zhu
> Cc: Jeffrey Hutzelman; [hidden email]
> Subject: Re: FW: I-D ACTION:draft-zhu-kerb-anon-00.txt
>
> On Wed, Oct 19, 2005 at 02:02:00PM -0700, Liqiang(Larry) Zhu wrote:
> >
> > The client needs to know if the KDC understands the request-anonymous
> > KDC option, for that reason we need to the anonymous ticket flag. This
> > is because RFC4120 compliant KDCs ignore unknown KDC options.
>
> That's what AD-MANDATORY-FOR-KDC is there for :)

123