OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Comments below :

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

Tim (or anyone else)


i) the pre-authentication is in addition to the "normal" authentication 
protocol defined by Kerberos. So, although the principal may be passing 
a password in the authentication request, there may also be some 
pre-authentication data. Correct?
Tim> Yes, correct. Except that 'normal' does not involve passing a
password. There are never any passwords transmitted (or stored anywhere)
when using the Kerberos protocol.

ii) the pre-authentication method is indicated by a numeric value (not a

URI) which will eventually be registered with IANA.
Tim> Yes, correct.

iii) this is specific to Kerberos, not to other shared-secret type 
authentication methods, right?
Tim> Yes, correct.

If the above conditions hold, then I think the solution is to add an 
attribute of type xs:integer to the current XML schema for the 
KerberosProtectedTransport authentication context class.
Tim> This might work. Will have to see your documentation on this to
consider it further. What do others think ?

- JohnK

ext Tim Alsop wrote:

>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
>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
>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
>occurring - e.g. when you logon to a Windows Active Directory domain
>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
>Kerberos (PKINIT), use of two-factor authentication tokens, use of one
>time password etc.) describes the pre-authentication method which
>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
>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
>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,
>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?
>- JohnK
>ext Tim Alsop wrote:
>>Yes, this is correct. The Kerberos protocol defines an extensible way
>>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
>>number that is (or will be soon) registered with IANA by IETF Kerberos
>>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
>>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 :-)
>>-----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;
>>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
>>>the PasswordType element, which can carry the Kerberos URN,
>>>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
>>to get a TGT, so it really needs to qualify the
>>case, I think.
>>-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]