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    

WebLogin multifactor protocol and design

Tom Jones tom.jones at oucs.ox.ac.uk
Tue Jul 12 08:03:14 PDT 2011


* Russ Allbery <eagle at windlord.stanford.edu> [2011-06-14 14:34 -0700]:
> Hello everyone,
> 
> This is the second part of the protocol work for adding multifactor
> support to WebAuth.  This part deals with the protocol for the interaction
> between the WebKDC and the WebLogin front-end, and between the WebKDC and
> the multifactor middleware.

I'm not sure I've completely understood the second tranche of 
proposals, so bear with me if this is the case.

Overall, there are a few places where assumptions may have been
made about the range and number of second-factor mechanisms that 
a user could be subscribed to at a site, and about how the mechanism
could be selected.

In your first message, you listed three mechanisms (printed list,
TOTP SMS, soft TOTP).  I wasn't sure whether one user could be
signed up for multiple of these schemes.  I think it's pretty
likely that we will want one user to be able to subscribe to multiple
mechanisms, here.

> 1. To the login token passed by the WebLogin server, add the additional
>    token attribute "otp", which can hold the OTP code.  A login token must
>    contain either the "p" attribute or the "otp" attribute.

If a user is subscribed to multiple OTP mechanisms, it doesn't
appear possible to communicate which one the supplied OTP is for.
Would the WebKDC be expected to try and see if the OTP is valid
for each, or is there an assumption that each user will only be
subscribed to one OTP mechanism?

> 2. A new XML element, <multifactorRequired>, is added to the
>    <requestTokenResponse> element.  If the WebKDC returns the error code
>    saying that the authentication requires a second factor, this element
>    will be included.  It looks like:
>
>        <!-- set in combination with a loginErrorCode of 19 if
>             multifactor authentication is required -->
>        <multifactorRequired>
>          <factor>{factor-code}</factor>
>          <!-- repeat for each factor code required by the WAS -->
>          <configuredFactor>{factor-code}</configuredFactor>
>        </multifactorRequired>
> 
>    The <factor> elements will list all the factors that the WAS requested,
>    or that the WebKDC decided to require for some other reason, and will
>    be used mostly for the UI if desired.  The <configuredFactor> attribute
>    tells the WebLogin front-end which second factor the user has available
>    to them, and controls the prompting.

It looks like the WebKDC will be performing the logic to
translate requirements like "loa=3" or "ia=o3" into the specific
mechanisms, and passing the results on to Weblogin.

So is "{factor-code}" (in both <factor> and <configuredFactor>)
constrained to values of the same codes used in ia/san tokens in the 
WAS-WebKDC protocol?  eg "o", "x"?  Or is the idea that these are
site-defined factor-codes, probably more specific (eg "vendor X token",
"vendor Y token", "message-otp-voice", "message-otp-sms-cellnetwork-X",
"message-otp-sms-cellnetwork-Y") defined at each site?

If it's the former, then I'm not sure this provides information
that's specific enough to result in informative prompting (eg: 
"Please enter the <N> digit code currently displayed on your 
<vendorX> widget", "Please enter the <M> character code that
was just sent to phone number #######").  I guess that if there was
only one mechanism with each rank per o# or x#, it would be
unambiguous.  But that seems like a rather artificial constraint.

If it's the latter (I don't think it is), then there is the question
of how the WebKDC / Weblogin is configured with information about 
these mechanisms.  I guess this would come in a later message, since
this one is just about protocols.

<configuredFactor> appears to be single-valued, implying an
expectation that each user is subscribed to a maximum of one
"factor", or second-factor mechanism, to use slightly different
terminology.

One possible scenario would be to have a user signed up to both
a realtime message OTP mechanism (say SMS) and a time-based OTP 
mechanism.  We may want a user to be able to select the one that 
is most convenient at the time (cell reception vs forgetting their
token), if both satisfy the LoA constraints in place.

Am I right in thinking that the above is too complex to be
achieved with the proposed protocols, both between WebLogin
and the WebKDC, and between the WebKDC and the middleware?

> webkdc-validate <username> <ip> <timestamp> <otp-code>
> [...]
> sms <username>

For the middleware commands, I think it also worth considering the
situation where a user is subscribed to multiple realtime message OTP 
mechanisms.  Say SMS and voice -- so the "sms" middleware command would
need generalising.  The question of multiple OTP mechanisms also
applies to the "webkdc-validate" middleware command.

I appreciate that your message was just about the protocols,
and you may intend to detail the configuration specification
later.  The configuration specification may help me understand which
component (WebLogin, WebKDC, middleware) is performing which tasks in 
terms of translating the LoAs and the other general constraints into 
the specific second-factor mechanisms to be prompted for and validated.

I think my main conclusion is that while "o#", "x#" and so on
are appropriate for WAS <-> WebKDC communication, when it comes
to internal communication within the WebKDC, more detail may
need to be expressed somewhere, and an additional level of abstraction
may be required.

The following table may be a realistic multifactor portfolio for
us in a couple of years:

 Mechanism                      |  Factor code  |   LoA
OTP sent over email             | o10           |  10
OTP over SMS                    | o15           |  15
OTP over Voice                  | o15           |  15
Soft TOTP                       | o15           |  15
TokenCorp TOTP - factory-seeded | o20           |  20
XYZCorp TOTP - site-seeded      | o30           |  30
ABC Corp TOTP - site-seeded     | o30           |  30
Soft X.509                      | x10           |  15
X.509 Smartcard site-managed    | x20           |  50

Now on to my other points, which I'm able to deal with more briefly.

I see that x509 doesn't feature in this tranche.  I guess the
simplest x509 scenario would be where the WebLogin component knows
that a location it serves is x509-protected by the web server
containing it.  So would it need to be able to tell the WebKDC
about this?

> <!-- login history only present for questionable logins -->

I was going to suggest leaving it undefined whether the presence
of login history means something is suspicious, but see that you've
already done this in the online draft.

Finally, as you stated in your message, this is mostly internal
to the Webauth servers.  Indeed at our site, the same team runs the
Weblogin and WebKDC components and the same team would run the middleware
component.  So it would not be a short-term disaster if we had to
diverge from upstream protocols here.

If the WebKDC-internal protocols are forwards-compatible, this may
help foster integration of authentication products into Webauth,
whether by vendors or the community.  Once this starts occurring,
we would be at a disadvantage if we had diverged.  For the same
reason, forwards-compatibility may be a desirable design objective
for the work you're currently doing.

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


p.s. The following minor typing errors exist in the online
document currently:

- "A login tokens" -> token
- "te WebKDC" -> the
- "The US" -> UA (twice)
- " UA>" -> UA



More information about the webauth-info mailing list