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, Liberty's definition of PrincipalAuthenticationMechanism is 

'The method that a Principal employs to perform authentication to local
system components.'

With this interpretation, for the 'proxied Kerberos' situation, there is no
PrincipalAuthenticationMechanism (as is the case for Liberty's similar
classes like Password and PasswordProtectedTransport).

Wrt Polar's concern about the trustworthiness of an individual who would use
this mechanism, it appears to me that, ultimately, the issue is that the
password is shared with an 'extra' entity than that which will be able to
verify it. We could support this distinction in a number of ways, one
possibility would have the IDP include an 'ExternallyVerified' element
within the password element, and specify a Kerberos URI as its content. 

So the classes for the two cases could be something like

1) Real Kerberos

-PrincipalAuthenticationMechanism
	-Password
-Authenticator
	-SharedSecretDynamicPlaintext
		-Kerberos
-AuthenticatorTransportProtocol
	-SSL

2) Proxy Kerberos

-Authenticator
	-Password
		-ExternallyVerified
			-Kerberos
-AuthenticatorTransportProtocol
	-SSL

Make sense?

Paul

>-----Original Message-----
>From: John Kemp [mailto:john.kemp@nokia.com]
>Sent: Wednesday, April 14, 2004 9:24 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
>
>
>ext Paul Madsen wrote:
>
>>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.
>>
>>  
>>
>Sure....
>
>>'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?
>>
>>  
>>
>I see what you're saying - that maybe the relying party maybe doesn't 
>care whether Krb was used to validate the authentication - although I 
>believe Polar did mention a use-case for marking the Principal 
>as being 
>untrusted if they choose to use their password in this way, so 
>maybe the 
>information *is* useful :)
>
>We could use PasswordProtectedTransport in this case, but also 
>allow the 
>IdP to claim that they used Kerberos to validate that authentication - 
>by allowing a PrincipalAuthenticationMechanism statement to be 
>added to 
>a conforming instance document of the PasswordProtectedTransport class 
>(currently the class *doesn't* allow this). What do you think of that?
>
>>With respect to ii) below, makes sense to me.
>>  
>>
>OK.
>
>- JohnK
>


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