[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
Paul, No, the relationship is not 1:1. Any preauth type can be used to obtain an initial tgt. To make matters worse, there are discussions about using multiple pre-auth methods to get an initial ticket, however this is not used/possible today. Reference: "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." Yes, this would be possible, but it would require changes to all KDC's and the Kerberos IETF standards would need to be changed to allow this alteration. I think we prefer to use standard Kerberos products and technologies with SAML rather than proposing changes to Kerberos protocol to meet our needs. Reference: "I don't think it's 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" I am not familiar with this use case - is it documented anywhere ? Remember - Kerberos client does not meet a users workstation. A Kerberos client is installed on servers as well as workstations. I'm not sure this makes a difference to your comment because I am not familiar with credential collectors. Tim. -----Original Message----- From: Paul Madsen [mailto:p.madsen@entrust.com] Sent: 04 June 2004 14:15 To: Tim Alsop; John Kemp Cc: security-services@lists.oasis-open.org Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]