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    

Understanding WebAuth

Russ Allbery eagle at
Sat May 15 16:11:58 PDT 2010

Liam Atkinson <liam.atkinson at> writes:

> I am currently working on a formal analysis of the security of WebAuth
> for my Masters project. During the course of trying to understand the
> protocol I have run into some problems, and I was wondering if anyone
> could help!

> 1) What is krb5_mk_req actually equivilant to in the Kerberos protocol?
> Asking for a ticket from the TGS?

No, although it does that as a side effect.  krb5_mk_req generates a
KRB_AP_REQ message.  See section 3.2 of RFC 4120.

The current terminology is confusing.  I'll fix the protocol specification
to use KRB_AP_REQ terminology.

> 2) When initially establishing a session key (that is, there is not a
> WebAuth key present at that time) is the encryption of the service token
> simply done with the Kerberos key? If so, what is the significance of
> the expiration time and session key being sent "out of band"?

I assume you mean the <getTokens> XML request from a WAS to the WebKDC to
acquire a webkdc-service token for later use?  The returned service token
is encrypted in the private key of the WebKDC.  The session key is sent
separately because the WAS cannot decrypt the service token.

Nothing in the WebAuth protocol is protected by Kerberos keys except for
the KRB_AP_REQ sent to the WebKDC when requesting a webkdc-token.
Everything else is done using WebAuth keys.

> 3) It is mentioned that SSL/TLS should be used to protect the
> communications between all of the components (WebKDC, UA, WAS). What
> exactly is required? Authentication, encryption or mesage integrity? Is
> unilatteral or bilatteral TLS required?

There are several links, so taking each one at a time.

For the connection from a WAS to the WebKDC to request a webkdc-service
token, TLS is used for authentication of the WebKDC to the WAS (which
provides protection against someone forging authentication credentials to
the WAS by impersonating the WebKDC), for encryption of the session key
returned by the <getTokens> call, and for message integrity for the same
reasons as authentication.

For the connection from the UA to the WebLogin server, TLS is used for
authentication of the WebKDC to the UA to prevent phishing and for
encryption of the user's password, webkdc-proxy cookie, or other
authentication credentials.

For the connection from the UA to the WAS, TLS is used for encryption of
the id and app tokens, since possession of either would allow an attacker
to impersonate that user to that WAS.  If you don't care about
impersonation (if, for instance, you're using WebAuth to protect a
low-value resource), you can disable TLS from the UA to the WAS without
compromising more than the authentication of that user to that service.

Of course, most things protected with WebAuth have content that itself
should be encrypted for reasons other than just protecting the WebAuth
protocol itself.

> 4) Finally, with regard to the nonce sent in tickets - when is this
> returned?

I assume you mean tokens.

I'm not sure what you mean by "returned."  Could you rephrase the
question?  The nonce is documented in section 5.1 of the protocol

    {nonce} is 16 random bytes and is encrypted with the rest of the data
    in the token. It is used to ensure that two tokens with the same data
    and same encryption key don't encrypt to the same value.

Every token contains a nonce.  It's part of the general WebAuth token

Russ Allbery <eagle at>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University

More information about the webauth-info mailing list