Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

WebAuth multifactor protocol and design

Russ Allbery eagle at windlord.stanford.edu
Wed Jun 29 13:16:24 PDT 2011


Tom Jones <tom.jones at oucs.ox.ac.uk> writes:

> Firstly, thanks for sharing the proposed changes at the design stage
> (and I hope I'm not too late providing this feedback).

Nope, not a problem, particularly for comments that are very easy to
accomodate.  :)

> Should X.509 have a corresponding X.509-#, like otp does?  X.509 could
> apply to a situation where the client manages the secret key in a file
> on a normal filesystem.  Or it could apply to a smartcard designed to
> inhibit the key ever leaving the smartcard.  So X.509 seems to apply to
> a broad range of levels of assurance.

This is a good idea.  I've gone ahead and added this.

> An additional possibility is to distinguish, for both otp and X.509,
> between the client's secret existing in a hardware device physically
> designed to inhibit cloning of the device, and other cases.  For example
> "hwotp" and "hwX.509".  That said, we would manage fine without this if
> the site-specific "-#" qualifier is available for both otp and X.509.

This is an interesting point.  I'm not quite sure whether to draw this
distinction directly in the protocol or not.  On one hand, I do think
that's going to be a common distinction that a lot of sites will want to
make.  But, on the other hand, that line is a little fuzzy, particularly
since I expect to see a lot more software agents built into cell phones
that may or may not have some anti-cloning assistance from the cell phone
software but which aren't quite hardware tokens either.

For the time being, I'm leaving just the numbered varients, but this is
one of those things that's quite easy to change, and I'm trying to make
sure the protocol doesn't make it hard to fiddle with this later.  I think
we'll learn a lot from having deployed this in production and seeing what
problems people run into.

> Before considering what other two-factor mechanisms we may use in
> future, I should ask what the change process is likely to be for this
> part of the protocol.  If review within a couple of years is likely,
> then the list of mechanisms doesn't have to contain all the likely
> future mechanisms yet.  In any case, new authentication technologies are
> likely to crop up as time goes by, so perhaps a review cycle could be
> explicitly stated anyway.

Oh, my intention is to include whatever authentication factors people say
they want, provided they make sense.  The review process should be way
faster than a couple of years.  We're anticipating adding additional
factors for whatever we run into at Stanford, and I'm happy to do the same
thing for any other site.  The code changes are fairly minimal, since the
code is mostly agnostic about the specific factors.  Most of the changes
will be in site-specific middleware or configuration that maps
authentication methods to factor codes.

> If the protocol contained a way for site-specific mechanism identifiers
> to be created, we would be able to use this for these putative future
> mechanisms.  But we'd prefer to have them all defined in the WebAuth
> protocol, to limit the amount of site-specific semantics we need to
> define and communicate.

Yeah, I would too, and also to avoid the problem of collisions.  The code
will handle arbitrary site-defined factors, but I'd rather list as many as
possible directly in the protocol specification.

In doing this round of WebAuth updates, I've already found that the
protocol specification could use some significant expansion and reworking
to make it clearer and to use more standard terminology, but I've not yet
had a chance to do that.  In the meantime, however, the specification with
at least the changes to the token format for multifactor is available in
draft form at:

    http://www.eyrie.org/~eagle/software/webauth/protocol.html

As always, we're on a timetable, and the 4.0.0 release will handle
Stanford's needs but may not be that great for other people due to only
having managed to implement our middleware needs.  But my intention is to
do a fairly fast 4.1.0 follow-on, broadening that support, and of course
I'm always very happy to incorporate anything that other people discover
they need.

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University



More information about the webauth-info mailing list