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

Tom Jones tom.jones at oucs.ox.ac.uk
Wed Jun 29 07:10:00 PDT 2011


* Russ Allbery <eagle at windlord.stanford.edu> [2011-05-25 15:24 -0700]:
> Hello everyone,
> 
> We're starting work on adding multifactor authentication support to
> WebAuth and have been designing the necessary protocol changes and how the
> configuration options will be handled.  This message is a summary of the
> current tentative design.  As yet, no code has been written, so now is an
> ideal time to provide input, requirements, and feedback.
[...]

Russ,

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

The initial authentication token and session authentication tokens,
in each direction, can hold multiple values.  This is good (and
contrasts with some other software in this field where it is currently
very inconvenient to work with more than one authentication context
class reference, to use SAML terminology).

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.

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.

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.

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.

  best wishes, Tom Jones.

-- 
Tom Jones, Systems Development and Support Section
Computing Services, University of Oxford



More information about the webauth-info mailing list