RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication

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

John,

I will try and help.

The Kerberos protocol is (as you know) defined in IETF RFC1510, however
(you probably didn't know) it is now defined in a IETF draft called
Kerberos clarifications which obsoletes RFC1510 (see
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifica
tions-05.txt). Our documentation needs to reference this correctly.

Anyway, if you look at http://www.ietf.org/ids.by.wg/krbwg.html you will
see various drafts are being worked on at present within IETF Kerberos
Working Group. The one of interest is the pre authentication framework
which Sam Hartman is progressing. In this document it describes pre
authentication as "a mechanism for proving the identity of a principal
and for better protecting the long-term secret of the principal."

To help you understand - pre authentication is optional, but
recommended. For normal password based authentication it is common to
use an encrypted timestamp as the pre-authentication method to further
improve the security of the authentication request. Most people use
Kerberos authentication and don't realise that the pre-authentication is
occurring - e.g. when you logon to a Windows Active Directory domain you
are using a pre-auth method with timestamp to help prove your identity
and reduce chance of replay attacks etc.

So, each Internet draft (e.g. use of smart cards for authentication with
Kerberos (PKINIT), use of two-factor authentication tokens, use of one
time password etc.) describes the pre-authentication method which should
be used and describes the pre-authentication type. The pre-auth type is
a unique number which is currently not stored anywhere centrally, so
each draft has to be referenced to find the pre-auth type, but in future
IANA registry will be used to refer to the type number for a particular
pre-auth method.

I propose that we store the pre-auth type somewhere in the
authentication context since it allows us to determine how strong the
authentication was, or what method was used in addition to knowing that
Kerberos was used with a password.

I hope this is clearer ?

If any doubts or questions please let me know.

Thanks, Tim.

-----Original Message-----
From: John Kemp [mailto:john.kemp@nokia.com] 
Sent: 04 June 2004 04:23
To: Tim Alsop
Cc: p.madsen@entrust.com
Subject: Re: [security-services] RE: AuthenticationMethod /
NameIdentifier and Kerberos authentication

Tim,

Just so that I have this straight in my head, can you help me out with 
this pre-auth concept? My understanding of Kerberos (admittedly small, 
and out of date) was that the principal supplies a password which the 
authentication authority then encrypts with a shared secret key, passing

it back for the client to decrypt. So, the principal authentication 
method is a password and the network authenticator is the password 
encrypted with the shared secret. How does pre-authentication fit in 
with that model, and the different methods? I imagine all you're really 
looking for is an attribute in the authentication context class that 
holds this data. Where can I find a list of the pre-auth methods, or 
more information to check my thinking on this?

Cheers,

- JohnK

ext Tim Alsop wrote:

>Yes, this is correct. The Kerberos protocol defines an extensible way
to
>get a users initial Kerberos ticket (tgt) and preauth is the way that
>Kerberos can support multiple technologies (e.g. smart cards, token
>devices, one time password). Each preauth type is defined with a unique
>number that is (or will be soon) registered with IANA by IETF Kerberos
>WG. 
>
>So, in our standards work we need to describe clearly how Kerberos can
>be represented in a SAML assertion and allow any pre-auth data type to
>be described, thus allowing a SAML site to make decisions based on the
>type of authentication used. Previously I had suggested we add
something
>like :pa-data-type:<n> (n = unique number describing the preauth type)
>to AuthenticationMethod, but I think we decided this was better
>described in some sort of Context class instead - this is what I was
>expecting to see in the AuthnContext draft ... I think :-)
>
>Tim.
>
>-----Original Message-----
>From: Scott Cantor [mailto:cantor.2@osu.edu] 
>Sent: 26 May 2004 22:21
>To: 'John Kemp'; Tim Alsop; p.madsen@entrust.com;
>security-services@lists.oasis-open.org
>Subject: RE: [security-services] RE: AuthenticationMethod /
>NameIdentifier and Kerberos authentication
>
>  
>
>>The other case, where the actual authenticator is a password, is
>>represented already with the PasswordProtectedTransport class. 
>>As I mentioned yesterday, I added an ExternalVerification attribute to
>>the PasswordType element, which can carry the Kerberos URN, specifying
>>that Kerberos was used as the "pre-authentication" method. 
>>    
>>
>
>Pre-auth isn't meant in that sense, it's how you do the real Kerberos
>dance
>to get a TGT, so it really needs to qualify the
>Kerberos-Protected-Transport
>case, I think.
>
>-- Scott
>
>
>
>  
>