Subject: [dix] An HTTP-based solution for digital identity

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Jun 2006 13:31:21 -0400

Hi, folks.  I said I was working on a draft describing use cases and a
specific technical proposal.  I have that draft done and it
compliments my phishing requirements draft.  I expect to update the
phishing requirements draft based on several reviews I've received and
based on what confuses people about it when I have explained it to
them in person.

I was intrigued by Phil Hallam-Baker's idea to separate HTTP
authentication into two parts : one between a user and some
authentication/identity service and one between the authentication
service and the relying party.  It is important to standardize the
second protocol; while standard methods of authentication to a
identity service would be desirable extensions offered by specific
identity providers may be useful and can be supported.  Phil suggested
starting with something like http-digest.  I started doing that
mentally during the last IETF meeting.  I found that I was reinventing
a lot of the Kerberos ap-req exchange--the exchange used to
authenticate to the server.

I started thinking about reuse of deployed code and realized that it
would probably be desirable to use existing code rather than inventing
some new protocol.  New protocols are often more complicated than they
at first seem they need to be and I definitely think this would be on
exception.  So, I decided to put together a sketch of how you could
just use Kerberos to meet these needs.  I was shocked at how much of
the infrastructure necessary to do this is already available in
current web browsers.

So, I decided to write up a proposal on how to realize some of the
goals in this space using Kerberos and other related technologies.  I
also described the use cases I'm attempting to solve.  My use cases
are less ambitious than the DIX use cases; personally I think that is
a good thing.  I do believe that my proposal can be expanded to meet
all the use cases that impinge on protocol interactions.  My belief is
that this should be done gradually.

I'm sure someone out there is going to claim that Kerberos is a
horrible fit for this and that it is too complicated.  I encourage you
to specify an alternative in at least as much detail as I have done so
we can compare the complexity, functionality, reuse of technology and
ease of deployment of proposals.  While any comments are welcome,
alternative proposals or explanations of how I got use cases wrong may
make constructive discussion easier than comments of the form "this
sucks."

At some level, the DIX proposal is an alternative.  However as I think
more about this problem space, I'm coming to the conclusion that a
redirect based approach is not really in conflict with a longer-term
in-band approach.  My approach will work better for webdav, caldav and
other non-HTML-based approaches.  I think my approach may provide a
better user experience even for web pages once it is available.
However the DIX proposal can be deployed with much less effort.  If
both proposals end up using SAML to express information about
identity, they could be complimentary.

I do have some serious questions about whether a redirect-based
approach should be standardized.  I'll ask those questions in another
message.  I'm also talking to people interested in deploying
redirect-based approaches along with those who have done so, trying to
get a more informed opinion.

Any way, I'd like to draw your attention to
draft-hartman-webauth-00.txt.  Let the flames begin.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jun 2006 14:30:45 -0500

On Mon, Jun 19, 2006 at 01:31:21PM -0400, Sam Hartman wrote:
> service and the relying party.  [...]

Gosh, that sounds like a ticketing service...  Like Kerberos, actually.

Or we could make a ticketing service out of PKIX technologies.  Or out
of SAML/XMLdsig/XMLenc.  Or something totally new!

Or we could try to re-use specs.

:)

Yes, I see why you suggest Kerberos.

One argument I've seen against Kerberos is that it requires online
infrastructure, but I think it's now clear that all the good choices in
this space do (e.g., PKIX CRL and OCSP servers, online CAs, SACRED
servers, etc.).

That leaves the argument that Kerberos V KDCs know too many secret keys,
but Kerberos V has been getting PK technology added to it too, and in
the end the specs will allow users to make the public key vs. shared
symmetric key decisions (which I think is a good thing, provided that we
inform those making the choices of the relevant trade-offs).

However, the strongest arguments against Kerberos, that is, the
political ones, are also the most superficial.  I don't know how you
argue with fashion :)

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Jun 2006 16:49:44 -0400

So, I don't think the KDCs know too many secret keys argument is very
good when we are in a space where the state of the art is identity
providers knowing plaintext passwords.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jun 2006 15:53:44 -0500

> providers knowing plaintext passwords.

Point!  But again, that would only be a minor argument.  Fashion, well,
that's may be a tougher nut to crack.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2006 14:56:25 -0700

> make constructive discussion easier than comments of the form "this

Sam,

Well, it certainly would be straightforward to write up an alternative
proposal using some other underlying technology (X.509 ACs, S/MIME,
SSL/TLS client auth, etc.). I'm sure that that would have advantages
and disadvantages vis-a-vis this proposal. However, I submit that
we're not at the point where that level of analysis is helpful;
rather, we need to work out what general kind of system architecture
we want to have and only then will we have a framework for figuring
out what kind of protocol to build.

To that end, my next message will focus on trying to work through
those issues.

-Ekr

---

From: Troy Benjegerdes <[email-masked]>
Date: Wed, 28 Jun 2006 23:51:39 -0500

> this space do (e.g., PKIX CRL and OCSP servers, online CAs, SACRED

However, not all good choices in this space have such tight time
sychronization constraints as kerberos does. I think any proposal for
digital identity based on kerberos needs to also propose some mechanism
for relaxing the synchronized clock constraints that all the existing
kerberos implementations I am aware of impose.

I would really like to be able to use kerberos as a mechanism for
authenticating to a wireless mesh network. But in practice, some
percentage of the time there will be some node that has a fast or slow
running clock, or just got rebooted and has a clock set to 2004.

If you can solve authentication with a device with a fast or slow
running clock, then maybe we could make this same infrastructure useable
for some future deep space network in which relativistic effects on
clocks and time start making a difference.

I suppose the real question I am asking is can kerberos be securely extended
to use relative timestamps instead of absolute timestamps, or does this
somehow fundamentally break the security model?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Jun 2006 08:46:59 -0400

>>>>> "Troy" == Troy Benjegerdes <[email-masked]> writes:

    Troy> However, not all good choices in this space have such tight time
    Troy> sychronization constraints as kerberos does. I think any proposal for
    Troy> digital identity based on kerberos needs to also propose some mechanism
    Troy> for relaxing the synchronized clock constraints that all the existing
    Troy> kerberos implementations I am aware of impose.

Modern Kerberos does not have that constraint between the client and
the KDC.  (Or between the client and server).  It does have that
constraint between the KDC and server--which is kind of ironic given
there are no message flows directly between the KDC and server.

Yes, I should add that to the work necessary to use Kerberos in this
situation.  

I think relaxing the time constraint is doable.