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 / NameIdentifierand Kerberos authentica tion


ext Scott Cantor wrote:

>>It appears to me that the argument here is about whether 
>>using Kerberos in a particular way should be represented as a 
>>Kerberos authentication in the assertion - correct ?
>>    
>>
>
>That's maybe one aspect, but I think there's another aspect which is what
>the point of Method is in the context of various profiles. I guess I'm
>arguing that in the browser SSO profile, the real value is in describing the
>dialog between the browser and the IdP web server, not whatever might be
>happening behind the IdP scenes. I'm probably much more inclined to hand
>wave that as an IdP detail and I trust him pretty strongly.
>
>  
>
I think this is the key point. I agree with Scott that the 
authentication method in the SSO assertion should describe the 
authentication dialog between the browser and the IdP. But, as noted, 
this is not the whole story.

>You can see that in one case it *is* Kerberos between the browser and the
>IdP and the other case, it's not.
>
>  
>
Right. So in the case where it is not the Krb between the browser and 
the IdP, a different authentication method should be indicated, but it 
is also still possible to indicate that something else is happening 
"behind the scenes" at the IdP - using the authentication context. In 
this case, one statement might indicate that the authenticator 
transmitted over the network was a password, but there would also be the 
chance to state that the PrincipalAuthenticationMechanism was Krb. A 
relying party receiving such statements about the authentication might 
decide that a password authentication was good enough if the 
PrincipalAuthenticationMechanism was Krb, but not good enough if it was 
nil, or some other mechanism. Such policies would be decided and 
communicated by parties in business (or other) agreements.

>>then we need to clearly define when Kerberos authentication 
>>is involved, and when it is not involved. In my view if we 
>>are using Kerberos to get a tgt and service ticket to obtain 
>>the identity of a user to store in an assertion then we 
>>should be happy that Kerberos is being used - surely this is 
>>a clear distinction ?
>>    
>>
>
>I think "happy" slides into the irrelevant part we don't need to agree on.
>It's different in both cases exactly how much Kerberos is used and between
>which parties and the threat model is very different.
>
>  
>
And there is a clear distinction, which Scott made.

>>To be clear - you seem to be refering to one method being 
>>acceptable and one method not being acceptable. This is not 
>>under question. What we are trying to conclude is whether 
>>they are both using kerberos, not which is better, worse, or 
>>acceptable. 
>>    
>>
>
>I'm arguing (unlike Polar) that both are acceptable to *some* people, but
>that (like Polar) one is clearly Kerberos to the relying party's decision
>making process, and the other may not be.
>
>Hiding that distinction is, IMHO, bad.
>
>  
>
I think that we should not hide the distinction, and I also don't think 
we *need* to hide the distinction - both pieces of information can be 
supplied by the IdP.

- JohnK


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