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

Hi John, I assume you mean adding this attribute to the
PrincipalAuthenticationMechanism in core schema and then using it in a
KerberosProtectedTransport class?

As a complication, while a Principal may use password or smart-card or
PKINIT to authenticate to the KDC, from the point of the view of the SAML
authority that the principal uses a ticket to authenticate to, the
authentication mechanism would be SharedSecretChallengeResponse.

Does Kerberos itself allow the KDC to advertise which of the supported
authentication mechanims was used so that the SAML authority could create an
appropriate context statement ?


>-----Original Message-----
>From: John Kemp [mailto:john.kemp@nokia.com]
>Sent: Friday, June 04, 2004 8:08 AM
>To: ext 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" 
>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?
>ii) the pre-authentication method is indicated by a numeric 
>value (not a 
>URI) which will eventually be registered with IANA.
>iii) this is specific to Kerberos, not to other shared-secret type 
>authentication methods, right?
>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.
>- 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 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 
>>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, 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?
>>- 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 unique
>>>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 to
>>>>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]