OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

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


Subject: RE: SAML attributes for Kerberos


> OK; there's a bit of confusion here, in part because I think we're talking
> about two different things.  I don't have a copy of the Kerberos SSO
> profile document handy at the moment, but my recollection is that this is
> primarily about using Kerberos to authenticate to the IdP, and possibly
> also to an SP.  That's interesting, but not the problem Russ and I are
> working on.

Yes, the attribute profile is the only document I'm trying to leverage here.

> Thus, what we're trying to do is provide a means for the IdP to forward to
> an SP those credentials which the SP is authorized to have.  Whether the
> IdP obtains these credentials via S4U, by being co-located with the KDC
or,
> as in our case, by having the user's password (and thus a TGT in the
user's
> name), is IMHO immaterial to the discussion at hand.  The important
> question is, once the IdP has credentials, how does it forward them to the
> SP?

Right. The IdP/KDC relationship is out of scope of the attribute profile.

> Fortunately, Kerberos does provide a standardized way of conveying
> credentials from one place to another, in the form of the KRB-CRED
message.
> This is described in RFC4120, sections 3.6 and 5.8.  Unfortunately,
> construction of a correct KRB-CRED message requires encryption of some
> parts of the message, using a Kerberos enctype and a key shared by the two
> parties involved; in this case, the IdP and SP.  This poses an interesting
> challenge if there is not already a shared secret; for example, if the IdP
> and SP are operated by different members of a federation.  However, I'm
> confident we can find a solution.

Can you clarify for me who needs access to the shared key? Is this something
that the Kerberos libraries would need to be able to derive from state that
only it would have access to, or is it supplied from outside to the relevant
Kerberos library APIs?

If it can be passed in from outside, than among other mechanisms, one could
generate a key, apply a key transport algorithm from the XML Encryption
standard, and pass the resulting EncryptedKey as an attribute, either within
this attribute's value or alongside it.

-- Scott




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