[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) 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? 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: >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-clarific a >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]