Re: [saml-dev] Confirming how holder-of-key profile works

[Tom Scavo <trscavo@gmail.com>]

Luis, I'm cc'ing the SSTC public comment list even though the profile
you ask about below is not under public review at this time.

On Thu, Apr 2, 2009 at 3:34 AM, luismi alvarez santana
<luismi.alvarez@gmail.com> wrote:
>
> I agree with you that itīs rather unlikely an IdP with a policy that
> permits the release of all the attributes without a previous explicit
> request of some of them, but I was thinking in an scenario where the
> userīs role (I mean the issuer of the request) were played by a device
> with few capabilities (at least, less capabilities than a browser),
> and where it was possible a generic <saml:request> valid to be used in
> different domains and with several IdP containing each of them
> different attributes (of course, in this situation the different IdP
> must permit the release of all the attributes)

I understand.  This is perhaps one reason why you don't see
self-queries in practice (at least in my experience).  If you don't
tell the IdP what you want and who you want it for, the IdP really has
no idea what to issue.  Since it's a self-query, an IdP *might* return
all attributes, but there are significant privacy concerns that would
prevent most IdPs from doing so (I think).

> In a scenario like that, iīve found that ther is another holder-of-key
> profile that (i think) fits in a more accurate way: SAML V2.0
> holder-of-key assertion request profile.
> In order to decide if this profile could be used, Iīd really
> appreciate that somebody could resolve a doubt. In the working draft
> 01 (7 Dec 2008) itīs said that "the SAML exchange MUST be mutually
> authenticated and integrity protected. Mutually authenticated SSL/TLS
> MUST be used for this purpose".
> Would it be possible that SAML exchange through a secure (with
> mutually authentication and protection of integrity) protocol
> different than SSL/TLS? For example, using methods in a layer 2 secure
> protocol like PEAP, EAP-TLS or similar.

Yes, that's a good question.  I struggled with that (and other issues)
in the first draft.  In the end, I made conservative choices
throughout.

I agree this security requirement needs to be relaxed for generality.
I'll try to rewrite it in the second draft.

Thanks for the comments,

Tom Scavo
NCSA

> 2009/3/29, Tom Scavo <trscavo@gmail.com>:
>> On Sun, Mar 29, 2009 at 6:26 AM, luismi alvarez santana
>> <luismi.alvarez@gmail.com> wrote:
>>> Thank you very much Tom. Youīve answered all the questions (or better
>>> youīve confirmed the ideas Iīd extracted).
>>>
>>> I have only one question (or confirmation) more. Iīve read in SAML
>>> Core (3.3.2.3 Element <AttributeQuery>) that if there is no attributes
>>> specified in the saml attribute query, the saml response issued by IdP
>>> will contain "all attributes allowed by policy". Does it mean that in
>>> the previous scenario (explained in the first mail) issuing a saml
>>> request by the user with no attributes specified in it, we would
>>> obtain a saml (holder-of-key assertion) response by the IdP, with ALL
>>> the attributes associated to the subject (the user) in that IdP?
>>
>> Well, first I'll note this question has nothing to do with
>> holder-of-key subject confirmation since the same is true regardless
>> of the requester.  The spec says it all: "all attributes allowed by
>> policy."  There's no point trying to rephrase it for clarity since
>> that is as precise as it gets.  If the IdP's policy is to return ALL
>> attributes to a self-requester, then that's what you'll get.  I rather
>> doubt an IdP would have such a policy but that's besides the point.
>>
>> Unless you (the requester) knows the IdP's policy with respect to
>> attribute release, it's almost always better to ask for specific
>> attributes in the request.
>>
>>> Thanks Luis M. Alvarez
>>
>> Hope that helps,
>> Tom
>>
>>> 2009/3/28, Tom Scavo <trscavo@gmail.com>:
>>>> On Sat, Mar 28, 2009 at 4:20 PM, luismi alvarez santana
>>>> <luismi.alvarez@gmail.com> wrote:
>>>>> Hello everybody,
>>>>>
>>>>> Iīve just read the SAM V2.0 Holder-ok-key Assertion Profile (CD 01, 9
>>>>> March
>>>>> 2009), and Iīd really appreciate a confirmation about what I think Iīve
>>>>> understood.
>>>>
>>>> I'm not really seeing any questions or comments in your message, but
>>>> since this document is in its formal Public Review period right now,
>>>> I've cc'd the security-services-comment list just in case.
>>>>
>>>>> The scenario Iīm interested in, implies an attesting entity (a
>>>>> user) that tries to get some of their attributes from a SAML issuer (an
>>>>> IdP)
>>>>> in order to use them later in an access to a relying party (a SP). In
>>>>> this
>>>>> scenario, the steps would be:
>>>>>
>>>>> 1.- The user (acting as the attesting entity in the holder-of-key
>>>>> profile)
>>>>> build an attribute self-query saml assertion and send it to the IdP
>>>>> (acting
>>>>> as the SAML issuer)
>>>>
>>>> I think you mean a self-query SAML *request* but yes, that is one use
>>>> case relevant to this profile.
>>>>
>>>>> 2.-IdP issues a holder-of-key assertion containing the attributes
>>>>> requested.
>>>>> In this assertion the subject element would refer to the users
>>>>> identification used in the <saml:attributequery>, and the whole
>>>>> assertion
>>>>> were bound to X509 data OF THE USERīS CERTIFICATE (wasnīt it?).
>>>>
>>>> If I'm understanding you correctly, you're suggesting that the IdP
>>>> might bind a <ds:X509Certificate> element to the
>>>> <saml:SubjectConfirmation> element, correct?  Yes, that is covered by
>>>> this profile.
>>>>
>>>>> This implies
>>>>> that IdP NEEDS to know the X509 certificate of the user.
>>>>
>>>> Yes, that's an important point.  Taking the relevant excerpt from the
>>>> profile:
>>>>
>>>> "the SAML issuer MUST possess an X.509 certificate known to be
>>>> associated with the attesting entity"
>>>>
>>>> This profile doesn't say how the SAML issuer comes to posses such a
>>>> certificate, however.  That is left to higher-level profiles.
>>>>
>>>>> 3.- The holder-of-key assertion would act like an authenticating token,
>>>>> when
>>>>> would be presented to an SP (acting as the relying party), and the user
>>>>> would prove the possession of the X509 certificate.
>>>>
>>>> Yes, by proving possession of the private key corresponding to the
>>>> public key bound to the certificate.
>>>>
>>>>> In this step I then
>>>>> understand three things: (a) SP doesnīt need to know the X509
>>>>> certificate
>>>>> BEFORE the presentation of it by the user (on the contrary thet IdP,
>>>>> that
>>>>> it
>>>>> does)
>>>>> (b) It isnīt needed any other authentication process, because itīs more
>>>>> than
>>>>> enough the comparison of the X509 data contained in the assertion with
>>>>> the
>>>>> X509 presented by the client (and the associated private key)
>>>>> (c) SP doesnīt need to issue another <saml:attributequery> to the IdP
>>>>> (as
>>>>> in
>>>>> a normal access of a user with a token to an SP), because itīs able to
>>>>> extract the attributes contained in the holder-ok-key assertion, and
>>>>> process
>>>>> them (for example with the intervention of a PDP, PEP entities)
>>>>
>>>> If I'm understanding you correctly, all of that is true, yes.
>>>>
>>>>> Could anyone help me to confirm if the exposed scenario would be
>>>>> realistic?
>>>>
>>>> I think you've described the scenario quite accurately in fact.  Is
>>>> there a question or comment in there that I missed?
>>>>
>>>>> Thank you very much in advance, and, please, sorry for the bad english
>>>>> language I have.
>>>>
>>>> No problem.
>>>>
>>>> Tom Scavo
>>>> NCSA
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org
>
>