RE: AuthenticationMethod / NameIdentifier and Kerberos authentica tion

[Tim Alsop <Tim.Alsop@CyberSafe.Ltd.UK>]

Title: RE: AuthenticationMethod / NameIdentifier and Kerberos authentica tion

Scott,

The approach where a Kerberos client is on the web server normally works something like :

1. browser presents userid/password to web server.
2. Web server uses Kerberos protocol with pre-auth to obtain a tgt by sending an as-req to KDC
3. The tgt is used to obtain a service ticket for the actual web server
4. The tgt is cached / baked into a cookie to maintain session context for subsequent page requests.
5. The web server receives the service ticket and decrypts it to determine the principal name of the user.

Using this approach the web server is a Kerberos service and also a Kerberos client. This avoids a trojan horse attack where the web server might not be the real web server that the user submitted their userid/password to (over TLS). It also allows for kerberos enabled services behind the web server to be accessed using the credentials obtained on bahalf of the user at the workstation.

The other scenario is where a Kerberos client is on workstation or in browser, and Kerberos / pre-auth would also apply in this scenario.

So, in answer to your question - I can see this being meaningful because it represents a common and secure way of using Kerberos to authenticate a user and the pre-auth type in this instance will likely be a 1,2 or 3.

Thanks, Tim.

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: 12 April 2004 22:12
To: 'Tim Alsop'
Cc: 'John Hughes'; security-services@lists.oasis-open.org
Subject: RE: AuthenticationMethod / NameIdentifier and Kerberos authentica tion

> The pre-authentication type determines what Kerberos
> mechanism was used to authenticate, e.g. userid/password,
> token, smartcard. Just saying that a Kerberos method has been
> used is not clear enough.

I totally agree, I'm just saying that if the actual Kerberos client is
sitting on a web server, and the user is sending his password in the clear
or best case over TLS, that isn't Kerberos in any meaningful way I can see
for the purposes of an access control decision at the service end.

Preauth doesn't even factor into it because I can't even see calling it
Kerberos.

Certainly I think authn context captures these distinctions, but the old
method URI alone doesn't.

I guess I thought there was some agreement on that, but if this is still a
minority (or unique) position, the group can decide.

-- Scott