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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 19 Oct 2005 00:05:56 -0700

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey Altman
Sent: Tuesday, October 18, 2005 6:16 PM
To: [email-masked]
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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 19 Oct 2005 03:31:33 -0400

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

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

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 19 Oct 2005 15:23:49 +0200

> 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