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] Drafts for review: Kerberos & SAML profiles



On 18 Aug 2009, at 00:20, Scott Cantor wrote:

> Josh Howlett wrote on 2009-08-17:
>> My own interpretation (FWIW) of the WSS SAML token profile is that  
>> the
>> absence of text concerning the use of other confirmation methods did
>> not imply that other confirmation methods were not permitted.
>
> I'm sure that's true from a profile point of view, but I wouldn't be  
> so sure
> from an implementation perspective.

...

> Any implementation would have to have very specific knowledge of  
> what you
> were doing here to have any chance of it working.

Agreed.

> It's not going to just
> work with existing code.

Perhaps I've missed something, but having stared at the WSS SAML TP's  
HoK Processing Rules for a while, I don't understand how you can  
expect interoperability between any two HoK implementations in any  
case...

> So the question becomes how/where do you signal
> that difference to hook in the proper logic? And is it a good idea  
> to reuse
> not only the method URI but also KeyInfo child elements to represent
> something completely different from typical usage?
>
>> I suppose we could define a new type ('KerberosData'?) for KeyInfo  
>> whose
>> semantics were less ambiguous, but I'm wary of unnecessary invention.
>
> I suppose a logical place to start might be with whether any existing
> practice exists around Kerberos + KeyInfo.

Hmm, I guess you could use a <wsse:SecurityTokenReference> in the  
<KeyInfo> that points to a Kerberos security token. But the WSS  
Kerberos Token Profile doesn't provide a concise way of naming a  
principal, just various value types that are Base64 encodings of  
Kerberos messages.

That would require that the SAML Issuer was in possession of (say) the  
service ticket at the time that the assertion was minted, which I  
think would be rather challenging to choreograph if not impossible.  
Merely naming a principal is significantly simpler for both the SAML  
Issuer and the RP to process.

Alternatively, we could define a new value-type that was a Kerberos  
principal name (rather than one of the six value types defined in WSS  
Kerberos Token Profile).

Summarising, I think we have four possible approaches:

1. Use <KeyName> to identify a Kerberos principal name, and the HoK  
subject confirmation method. This avoids invention, but the bending/ 
abuse of the "names a key" HoK subject confirmation semantics is  
unattractive, at least (because it's actually naming a principal).

2. Define a new type for <KeyInfo> that unambiguously names a Kerberos  
principal, and use this with HoK subject confirmation method. This is  
still reasonably simple, but requires some modest invention.

3. Use <wsse:SecurityTokenReference> in <KeyInfo> with a new value- 
type that describe a Kerberos principal name, and also use this with  
the HoK subject confirmation method. This loosely tracks a path trod  
by precedent, but otherwise doesn't seem to add much over (2) (and  
arguably the introduces an unwelcome dependency on WSSE. This might be  
acceptable, for example, in WS use-cases, but not Web SSO use-cases.).

4. Define a new subject confirmation method. This require invention of  
a new subject confirmation method, but provides a clear distinction  
between the conventional x509 uses of HoK and Kerberos.

Any opinions on the above would be very welcome...

best regards, josh.


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