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, if your proposed 'pre-authenticated password' class is meant to
describe the 'poor man's Kerberos' scenario that Tim and Scott have been
discussing, to my mind Liberty already has a class that describes it, namely
PasswordProtectedTransport.

'The PasswordProtectedTransport class is identified when a Principal
authenticates to an identity provider through the presentation of a password
over a protected session.'

Admittedly, this class doesn't capture how the IDP validates the password,
ie. through a simple lookup or some proxied Kerberos authentication. Would
this distinction matter to a Relying Party? If so, perhaps this could be a
refinement of the passwordtype just as length is?

With respect to ii) below, makes sense to me.

Paul

>-----Original Message-----
>From: John Kemp [mailto:john.kemp@nokia.com]
>Sent: Wednesday, April 14, 2004 8:11 AM
>To: ext Paul Madsen
>Cc: 'Linn, John'; 'Scott Cantor'; 'Tim Alsop';
>security-services@lists.oasis-open.org
>Subject: Re: [security-services] RE: AuthenticationMethod /
>NameIdentifier and Kerberos authentication
>
>
>Paul,
>
>I agree with that solution, and I think we could also do the following:
>
>i) Create a "pre-authenticated password" class where the 
>PrincipalAuthMech was password, and the authenticator was set 
>to some value.
>ii) Make the SharedSecretDynamicPlaintext element carry a URI which 
>could indicate which specific method was used (Krb in this case).
>
>What do you think?
>
>- JohnK
>
>ext Paul Madsen wrote:
>
>>Although Liberty didn't define a Kerberos specific context 
>class, the piece
>>parts were intended to support the first kerberos scenario 
>described below
>>
>>The most relevant parts of the statement would be:
>>
>>1) PrincipalAuthenticationMechanism = Password
>>
>>2) Authenticator = SharedSecretDynamicPlaintext
>>(SharedSecretDynamicPlaintext is defined as 'The local system and
>>Authentication Authority share a secret key. The local system 
>uses this to
>>encrypt a randomised string to pass to the Authentication Authority'
>>
>>3) AuthenticatorTransportProtocol = SSL
>>
>>Paul
>>
>>  
>>
>>>-----Original Message-----
>>>From: Linn, John [mailto:jlinn@rsasecurity.com]
>>>Sent: Wednesday, April 14, 2004 7:30 AM
>>>To: 'Scott Cantor'; 'Tim Alsop'
>>>Cc: security-services@lists.oasis-open.org
>>>Subject: RE: [security-services] RE: AuthenticationMethod /
>>>NameIdentifier and Kerberos authentication
>>>
>>>
>>>I'll also agree with Scott and JohnK on this.  As I see it, 
>designating
>>>Kerberos as the method in an assertion issued by a SAML IdP 
>>>appropriately
>>>means that the IdP is issuing that assertion based on a 
>>>successful Kerberos
>>>protocol transaction with the user's client.  An alternative 
>>>where the IdP
>>>receives the user's password and itself performs a Kerberos 
>>>exchange on the
>>>user's behalf does involve Kerberos but doesn't constitute 
>>>Kerberos-based
>>>authentication to the IdP in the same sense.  It seems a reasonable
>>>description for this to annotate a top-level password method 
>>>indicator with
>>>an authentication context describing something like 
>>>"Kerberos-confirmed",
>>>though. 
>>>
>>>--jl
>>>
>>>-----Original Message-----
>>>From: Scott Cantor [mailto:cantor.2@osu.edu]
>>>Sent: Tuesday, April 13, 2004 10:24 PM
>>>To: 'Tim Alsop'
>>>Cc: security-services@lists.oasis-open.org
>>>Subject: RE: [security-services] RE: AuthenticationMethod /
>>>NameIdentifier and Kerberos authentication
>>>
>>>
>>>    
>>>
>>>>Anyway, I think JohnK mentioned using an Auth Context instead 
>>>>of putting the Kerberos pre-auth in the AuthenticationMethod 
>>>>statement ? What was the concensus on this, or has it not 
>>>>been discussed in detail yet ?
>>>>      
>>>>
>>>The latter. I think everyone agrees that it makes sense, but I 
>>>don't know
>>>that Liberty has defined any specific classes or statements 
>>>that deal with
>>>Kerberos.
>>>
>>>    
>>>
>>>>Maybe if Kerberos has been used, but not in the way we prefer 
>>>>(client in workstation/browser) we could still represent this 
>>>>method as a Kerberos method, but put something meaningful 
>>>>into a Context statement that gives more details on how 
>>>>Kerberos was used to authenticate the user ? That is in 
>>>>addition to the pre-auth method ? Just a suggestion ... Comments ?
>>>>      
>>>>
>>>Right. My criticism pertained to the old method. However, I 
>>>would be equally
>>>opposed to lumping this model into a general Kerberos context 
>>>class. I think
>>>it's closer to a "password" class with specific details 
>>>provided as to how
>>>the server is checking the password for accuracy that 
>mention Kerberos.
>>>
>>>-- Scott
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from the 
>>>roster of the
>>>OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/security-services/
>>>    
>>>
>>members/leave
>>_workgroup.php.
>>
>>To unsubscribe from this mailing list (and be removed from 
>the roster of the
>>OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/security-services
/members/leave
>_workgroup.php.
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php.
>
>
>  
>


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