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

[Paul Madsen <p.madsen@entrust.com>]

Tim, inline

>Paul,
>
>You make a good point regarding the KDC making available the pre-auth
>type - the simple answer is 'NO'. I have outlined what I think would
>happen so that we can agree whether this is possible, or not.
>
>1. A Kerberos client exchanges as-req and as-rep with KDC 
>resulting in a
>tgt (ticket granting ticket) being issued and stored in cache on
>Kerberos client machine. This exchange will have involved a form of
>pre-authentication (e.g. encrypted timestamp, pkinit differ-helman
>exchange, token challenge etc.) or none (not advisable, but possible).

If I understood your earlier mail correctly, for each authentication
mechanism there is an associated pre-auth mechansim (e.g. password has
encrypted timestamp). If that is the case (and if the relationship is
1-to-1) then why would not specifying the actual authentication mechanism be
sufficient.

>
>2. Once the tgt is available on Kerberos client machine only the client
>machine and the KDC know whether this tgt was obtained using
>pre-authetnication, and if so, what type was used during the as-req and
>as-rep exchange.

So, when the TGT gets presented back to the TGS in order to get a ticket for
authentication to the SAML Server, could the TGS insert the auth/pre-auth
info into the ticket at that point? If the auth information makes it into
the ticket then the SAML server can extract it from there.

>
>3. If we want to store the pre-auth type in the SAML assertion (hence,
>this discussion) we need to find a way to pass the pre-auth type from
>the Kerberos client machine to the SAML authority as well as the
>principal name and other information (e.g. tgt lifetime). I understood
>that this would be passed in the AuthnRequest ? Is this correct ?

I don't think its an AuthnRequest, if the Kerberos client is presenting a
ticket to the SAML server and getting back an assertion then this is the
'credential collectors' use case

Paul

>
>Any comments ?
>
>Tim.
>
>-----Original Message-----
>From: Paul Madsen [mailto:p.madsen@entrust.com] 
>Sent: 04 June 2004 13:40
>To: 'John Kemp'; Tim Alsop
>Cc: security-services@lists.oasis-open.org
>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 ?
>
>Paul
>
>>-----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)
>>
>>So:
>>
>>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?
>>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:
>>
>>>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
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>>    
>>>>
>>>
>>>
>>>
>>>  
>>>
>>
>
>