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

Russ Allbery eagle at windlord.stanford.edu
Tue Jul 12 10:15:31 PDT 2011


Tom Jones <tom.jones at oucs.ox.ac.uk> writes:
> * Russ Allbery <eagle at windlord.stanford.edu> [2011-06-14 14:34 -0700]:

>> 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?

In our environment, they would only be subscribed to one.  However, this
is a good point in general.  I think the simplest way to allow for that to
be indicated in the login token would be to add an additional parameter
that sets what factor the OTP code is for.  In other words, one would
include om=o1 or om=o3 in the login token.  This would be an optional
parameter; if not set, either the WebKDC is expected to know already what
factor the user is using, or is going to try all of them.

Note that the code in WebLogin for knowing and sending this information
may not be present in the first 4.0 release, but it's definitely something
that we can add later.  (And we may be able to add it in the first
release; it's not horribly difficult.)

>> 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.

WebLogin would get o3 or the like as a factor code.

> 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"?

Yes.

> 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?

I think since you have to assign o1 or x1 or the like to such things
anyway, it's easier to just use those codes consistently all the way
through and then reference them in your template to figure out what screen
to present to the user.  Then WebLogin can also just round-trip that code
(as described above) back to the WebKDC in the common case.

> 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
> #######").

The problem that I have is that I don't want to put too much stuff into
the protocol that has to be managed by the WebKDC and passed back to the
WebLogin server, since managing a bunch of string data in C inside the
Apache module is rather a pain.

At some point, at some level of complexity, I suspect you're going to need
to have the WebLogin front-end itself be able to query some sort of
database for supplemental information that you want to display to the
user, like their phone number or the name of their device.  Maybe I should
add another generic hook to the WebLogin front-end that can run
site-specific code and write the results into template parameters, which
are then passed into the view construction logic?

> 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.

It happens to be our use case here.  :)  So that's what the original
protocol was designed to handle, but I'm certainly not averse to expanding
it.

> <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.

Yes, to do what you want to do above, this will need to become
multivalued.  I'll make that change.

> 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.

Yeah, that makes sense.  We considered that here and then explicitly
rejected it, but mostly for UX reasons.

> 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?

Yup.  But I think it's a relatively easy fix.

>> 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.

Indeed.

> I appreciate that your message was just about the protocols, and you may
> intend to detail the configuration specification later.

Yeah, that is coming.  It's probably going to be a bit of a mess to start
with, since as always there's a bunch of implementation time pressure to
get our specific solution working for our specific needs, but I'm trying
hard to keep it open-ended enough that it doesn't get too locked into a
particular strategy.

> 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

It sounds like you are anticipating having a one-to-one mapping between
factor codes and specific mechanisms, which means that the templates
should be able to adjust wording appropriately.

> 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?

What I've done in the current code is add a hook to WebLogin that runs
site-local Perl code and returns the initial and session factors and LoA
for an Apache authentication.  That code will have access to the CGI
environment, so it can use, for instance, the mod_ssl environment
variables set by the user's authentication and do whatever site-specific
interpretation is needed (such as distinguishing between different issuers
and hence different levels of assurance or factor codes).

This information is then included in the webkdc-proxy token that's
generated by the WebLogin server for the Apache authentication case.

The configuration of the WebLogin side would look very much like the
configuration for Negotiate-Auth.

> 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.

Yes, definitely.

> 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

Ah, thank you!  Will fix.

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



More information about the webauth-info mailing list