[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
Ron,
First I will recount where I think we are in this discussion
and what the potential outstanding issues are and then
I provide a suggestion for addressing the situation.
(bottom line (to avoid reading all the details): suggestion
is to have STR2 point to a BinarySecurityToken with the attester
cert (similar to section 3.3.2 of the X.509 profile, except in
our case the sig ref points to the assertion and the sig keyinfo
points to the BST):
Recount of discussion:
I believe we are in agreement on the "unsigned assertion"
case where the attester signs both the assertion and the
message body and the basis of trust from the receiver
perspective is the public key of the attester with which
the attester may verify the signature covering both the
body and the assertion and based on the recipient's trust
in the attester's certificate all the relevant information
is trusted.
In addition, in the above case we put the attester's certificate
in the saml:SubjectConfirmation/saml:SubjectConfirmationData/
ds:KeyInfo element using the SCD element to contain the KeyInfo
rather than the SC element which is intended for the subject
certificate info.
Further, I agree that if we apply the same procedure as above
to the "signed assertion" case that we would break the
signature on the assertion, and as you indicate using some kind
of transform that doesn't include the attester KeyInfo element
is probably not feasible.
However, I think the signed assertion case raises some fundamental
issues about the basis of trust the receiver has on request. If
the signed assertion is not re-signed by the attester, then the
recipient effectively must now establish two bases of trust: one
with the attester and one with the assertion issuer. This may
be fine for some use cases, but, in general I think that a
recipient would prefer to keep their basis of trust as simple
as possible and make one agreement with the attester and let
the attester be responsible for all the relevant info in the
request.
Here is a suggestion that I think might address all the
above considerations:
That being said, an alternative means for the attester to sign
both the assertion and the content without breaking the signature
on the signed assertion would be to have the STR in the attester's
Signature/KeyInfo element (wsu:Id="STR2") point to a
BinarySecurityToken which would contain the attester's certificate
used to verify the signature. This approach could be used for
both the unsigned assertion and signed assertion cases without
interfering with the signature if it exists on the assertion.
Rich
-----Original Message-----
From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
Sent: Thursday, January 29, 2004 10:16 PM
To: Levinson, Richard; wss@lists.oasis-open.org
Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
Rich,
In the sender-vouches case, we proposed that the attesting entity define (by
putting a reference to a key in subject confirmation) and protect(by signing
the assertion) the key binding.
We have described how such an assertion would be used in the KeyInfo of a
Signature to bind the assertion to message content.
One problem with this approach is that the asertion cannot be signed by an
assertion authority (other than the attesting entity).
Perhaps the keyInfo element of the assertion's subjectConfirmation element
could be left out of the calculation of the on assertion signature. This
would
allow the attesting entity to change it without invalidating the signature.
I don't know if something like this would be feasible, although I
suspect not.
In which case, it would seem that the only easy way to allow the attesting
entity to define the key binding within the assertion (as proposed) would be
to require that sender-vouches assertions be unsigned until the attesting
entity signs them.
Ron
-----Original Message-----
From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
Sent: Thursday, January 29, 2004 6:00 PM
To: Levinson, Richard
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
Rich,
The assertion must always be protcted (in addition to the message), but
sometimes it is the attester that protects the assertion (i.e
sender-vouches), and
sometimes(holder-of-key) it is a third party (i.e the assertion
authority) that
potects the assertion.
In both cases the attesting entity binds the assertion to the message
content.
In the protected (e.g.signed) assertion case, the attesting entity need not
protect the assertion, because it can only bind a different assertion to the
message, if it can demonstrate knowledge of the confirmation key in this
different assertion. Similarly the attesting entity cannot change the
content of the assertion, without invalidating the protection of the
assertion.
Ron
Ron Monzillo wrote:
> Thanks Rich,
>
> I'd hope others will comment on this as well.
>
> The attester is both authorizing the subject assertion and attesting
> for the presence
> of the subject.
>
> It authorizes the assertion contents , by signing the assertion, which
> it had previously
> configured to authorize it as proxy for the subject.
>
> As I mentioned previously, this only makes sense if the assertion was
> not signed
> by the assertion authority. If the assertion was signed by the
> assertion authority,
> then the same logic can be applied, except the signature done by the
> attesting
> entity need only digest the msg body.
>
> Ron
>
> Levinson, Richard wrote:
>
>> Ron,
>>
>> I will try to consolidate our 2 email threads where I was trying to
>> clarify how to use the V9 spec to implement sender-vouches for the
>> interop spec and post to the wss list for additional input from any
>> who are willing to delve into the details and provide further
>> comment.
>>
>> I think we are in total agreement in your alternative paragraph (from
>> email
>> 1 below):
>>
>> "As an alternative, maybe the assertion referenced from keyInfo
>> should be
>> the sender-vouches confirmed assertion, and it could contain in its
>> subject
>> confirmation, a reference to a key confirmed security token of the
>> attesting
>> entity. The attesting entity would put this reference in the
>> sender-vouches
>> confirmed assertion."
>>
>> as compared to my suggestion (from email 2 below):
>>
>> "Since we are doing sender-vouches, the subject confirmation
>> may be done using the sender's key.
>> i.e. since the subject doesn't actually sign
>> anything and the sender is the one confirming
>> that the info in the assertion can be used by
>> the receiver, then it makes sense that the sender's key be in
>> the KeyInfo of the SubjectConfirmation."
>>
>> Also, I believe that the WS-SAML Profile spec is the only place where
>> a definitive explanation of how to implement sender-vouches and
>> holder-of-key exists. So, to some degree, that spec has flexibility
>> to clarify the details of these protocols.
>>
>> Also, referring back to the SAML 1.0 core spec, the relevant elements
>> within the assertion are defined as follows:
>>
>> "The <SubjectConfirmation> element specifies a subject by
>> supplying data that allows the subject to be authenticated. It
>> contains the following elements in order:
>>
>> <ConfirmationMethod> [One or more]
>>
>> A URI reference that identifies a protocol to be used to
>> authenticate the subject. URI references identifying
>> SAML-defined confirmation methods are currently defined with
>> the SAML
>> profiles in the SAML Binding and Profiles specification
>> [SAMLBind]. Additional methods may be added by defining new
>> profiles or
>> by private agreement.
>>
>> <SubjectConfirmationData> [Optional]
>>
>> Additional authentication information to be used by a
>> specific authentication protocol.
>>
>> <ds:KeyInfo> [Optional]
>>
>> An XML Signature [XMLSig] element that specifies a
>> cryptographic key held by the subject."
>>
>> As I read the above, if we want to do this with one assertion
>> (instead of
>> having an in message and off message assertion in the V9 example), I
>> think
>> we could put the sender (attester) cert in ds:KeyInfo, but to keep to
>> the
>> letter of the spec this really would not be accurate, because that
>> element
>> explicitly says the corresponding key is held by the "subject", who is
>> not the attester, but the attestee.
>>
>> Therefore, I think to be compliant with the above we could put a
>> KeyInfo element containing the attester/sender cert in the
>> SubjectConfirmationData element.
>>
>> I suggest that makes sense because we are defining the
>> "sender-vouches" protocol in this document and we could say that for
>> the sender-vouches protocol that
>> the attester cert or ref to such cert MAY be placed in the
>> SubjectConfirmationData
>> element.
>>
>> It seems to me that this is a perfectly good way to implement
>> sender-vouches
>> since the SubjectConfirmation element is intended to "supply data that
>> allows
>> a subject to be authenticated" and that is exactly what we are doing by
>> supplying the sender cert which can be used to verify the signature
>> covering
>> the assertion which identifies the subject and binds the assertion to
>> the content which is also included in the sig. And since the receiver
>> implicitly
>> trusts the sender/attester by some out of band agreement, this procedure
>> effectively
>> authenticates the subject as far as the receiver is concerned.
>>
>> Therefore, to move forward with the example in the interop document,
>> that
>> is the approach I propose to take, which will allow the interop to work
>> on the basis of self-contained messages that do not rely on external
>> methods to obtain assertions or certificates.
>>
>> Rich
>>
>>
>>
>>
>> !***********
>>
>> email 1:
>>
>> ******************!
>>
>> -----Original Message-----
>> From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] Sent: Thursday,
>> January 29, 2004 11:56 AM
>> To: Levinson, Richard
>> Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>
>>
>> Rich,
>>
>> There may be a problem with the example, or perhaps with the
>> sender-vouches
>> approach, but I think in general the example is structured
>> appropriately. In
>> the example, the on-msg assertion, is referenced by STR2, and used by
>> the
>> attesting entity" to sign both the message body and a "sender-vouches
>> confirmed assertion (referenced via STR1).
>>
>> I changed this example to not include the sender-vouches confirmed
>> msg in
>> the assertion, and such that the attesting entity uses a holder-of-key
>> confirmed assertion (as apposed to a key in some X509 cert) to
>> protect the
>> vouched for message content and assertion (as required by section
>> 3.4.2.1).
>>
>> I tweaked the example in this way to give us a better look at how
>> sender-vouches is currently being profiled, and to bring to light
>> some potential weaknesses in the current use modle for sender-vouches
>> confirmed
>> assertions:
>>
>> For example, without an appropriate usage attribute value on STR1 and
>> without the sender-vouches confirmed msg being present in the msg, it
>> may not be easy for the receiver to understand the header.
>>
>> As an alternative, maybe the assertion referenced from keyInfo should
>> be the
>> sender-vouches confirmed assertion, and it could contain in its subject
>> confirmation, a reference to a key confirmed security token of the
>> attesting
>> entity. The attesting entity would put this reference in the
>> sender-vouches
>> confirmed assertion.
>>
>> [I realize that statements not assertions have confirmation methods,
>> but I
>> am purposely glossing over this level of detail]
>>
>> Such an approach would rekindle our discussion
>> about whether sender-vouches confirmed assertions must be signed by
>> an issuing authority, while on the other hand, it would allign better
>> with the chained approach suggested for using holder of key confirmed
>> assertions to
>> authorize proxies; in which case the authority would sign the top level
>> holder-of-key assertion containing a reference in its
>> subject-confirmation
>> to a key confirmed assertion authorizing a proxy.
>>
>> Ron
>>
>> Levinson, Richard wrote:
>>
>>
>>
>>> Ron,
>>>
>>> This is a more explicit comment on the sv scenario
>>> in section 3.4.2.3 that looks to me like it needs
>>> a couple things fixed.
>>>
>>> 1. line 745 the ConfrimationMethod is holder-of-key.
>>> shouldn't it be sender-vouches?
>>>
>>> 2. line 727, AssertionID ends with "...ebdfc",
>>> and on line 769 KeyIdentifier refers to AssertionID
>>> ending with "...ebdbe" which is
>>> different from line 727. (As explained below
>>> I think this might be more than a simple typo)
>>>
>>> 3. line 806 the STR in the Signature/KeyInfo refers to
>>> "...ebdfc" which is the Assertion on line 727,
>>> which presumably contains the key used to verify
>>> this signature in the SubjectConfirmation/KeyInfo
>>> element.
>>>
>>> A possible problem I see with this setup is that the signer is
>>> signing an assertion of which the signer itself appears to be the
>>> subject of the assertion, since the SubjectConfirmation/ KeyInfo
>>> indicates a key to verify the subject of the assertion, not the
>>> attester of the subject of the assertion.
>>>
>>> It would seem to me in this case that STR2 should point to the
>>> signer's key, not the assertion subject's key as it seems to now,
>>> although I am not sure at this point if the key in the assertion is
>>> intended to be the signer's or the subject's, since your original
>>> intention might have been to include 2 assertions which would
>>> explain the presence of the 2 different AssertionIDs.
>>>
>>> To locate the signer key we could either have a simple STR2 to a
>>> cert in the wsse header, or to a 2nd saml assertion, also in the
>>> message, containing the attestor's key.
>>>
>>> Please let me know what you think, since I am trying to make the
>>> interop example as consistent as possible with the profile.
>>>
>>> Thanks,
>>>
>>> Rich
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ronald.monzillo@sun.com [mailto:ronald.monzillo@sun.com]
>>> Sent: Tuesday, January 27, 2004 1:55 AM
>>> To: wss@lists.oasis-open.org
>>> Subject: [wss] Groups - WSS-SAML-09.pdf uploaded
>>>
>>>
>>> The document WSS-SAML-09.pdf has been submitted by ronald monzillo
>>> (ronald.monzillo@sun.com) to the OASIS Web Services Security TC
>>> document repository.
>>>
>>> Document Description:
>>> SAML token Profile
>>>
>>> Update of STR ValueTypes to use URIs as apposed to Qnames (issue
>>> 196). Changed use of STR to carry saml:AuthorityBinding element.
>>> Many edits to examples, including change to Sender-Vouches example
>>> to user STR Dreference Transfrom.
>>>
>>> Download Document:
>>> http://www.oasis-open.org/apps/org/workgroup/wss/download.php/5177/W
>>> SS-SAML
>>>
>>>
>>
>> -
>>
>>
>>> 09.pdf
>>>
>>> View Document Details:
>>> http://www.oasis-open.org/apps/org/workgroup/wss/document.php?document_
>>> id=51
>>> 77
>>>
>>>
>>> PLEASE NOTE: If the above links do not work for you, your email
>>> application may be breaking the link into two pieces. You may be
>>> able to copy and paste the entire link address into the address
>>> field of your web browser.
>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the
>>> roster of the OASIS TC), go to
>>> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou
>>> p.php
>>> .
>>>
>>>
>>>
>>
>>
>>
>>
>> !*********************
>>
>> email 2:
>>
>> ************************!
>>
>>
>> -----Original Message-----
>> From: Levinson, Richard Sent: Thursday, January 29, 2004 11:37 AM
>> To: 'ronald.monzillo@sun.com'
>> Subject: RE: [wss] Groups - WSS-SAML-09.pdf - question on
>> Sender-vouches scenario
>>
>>
>> Ron,
>>
>> I have done a little more thinking on this and maybe we
>> can use things as they are if we interpret things in
>> the following context:
>>
>> Since we are doing sender-vouches, the subject confirmation
>> may be done using the sender's key.
>> i.e. since the subject doesn't actually sign
>> anything and the sender is the one confirming
>> that the info in the assertion can be used by
>> the receiver, then it makes sense that the sender's key be in
>> the KeyInfo of the SubjectConfirmation.
>>
>> If you agree with this then the only thing I think needs
>> to be changed in the text is:
>>
>> 1. line 745 change "holder-of-key" to "sender-vouches"
>>
>> 2. line 769 change "ebdbe" to "ebdfc"
>>
>> This way the SignedInfo ref covers STR1 which transforms to the
>> assertion. And STR2 in the Signature/KeyInfo now refers to the
>> assertion and is interpreted as meaning: use the KeyInfo in the
>> SubjectConfirmation as the key to verify this signature.
>>
>> For now I will work on this assumption and proceed with updating the
>> interop
>> spec.
>>
>> Please let me know if you think this all makes sense,
>>
>> Thanks,
>>
>> Rich
>>
>>
>> -----Original Message-----
>> From: Levinson, Richard Sent: Wednesday, January 28, 2004 5:56 PM
>> To: 'ronald.monzillo@sun.com'
>> Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
>>
>>
>> Ron,
>>
>> This is a more explicit comment on the sv scenario
>> in section 3.4.2.3 that looks to me like it needs
>> a couple things fixed.
>>
>> 1. line 745 the ConfrimationMethod is holder-of-key.
>> shouldn't it be sender-vouches?
>>
>> 2. line 727, AssertionID ends with "...ebdfc",
>> and on line 769 KeyIdentifier refers to AssertionID
>> ending with "...ebdbe" which is
>> different from line 727. (As explained below
>> I think this might be more than a simple typo)
>>
>> 3. line 806 the STR in the Signature/KeyInfo refers to
>> "...ebdfc" which is the Assertion on line 727,
>> which presumably contains the key used to verify
>> this signature in the SubjectConfirmation/KeyInfo
>> element.
>>
>> A possible problem I see with this setup is that the signer is
>> signing an assertion of which the signer itself appears to be the
>> subject of the assertion, since the SubjectConfirmation/ KeyInfo
>> indicates a key to
>> verify the subject of the assertion, not the attester of the subject
>> of the
>> assertion.
>>
>> It would seem to me in this case that STR2 should point to the
>> signer's key, not the assertion subject's key as it seems to now,
>> although I am not sure at this point if the key in the assertion is
>> intended to be the signer's or the subject's, since your original
>> intention might have been to include 2 assertions which would explain
>> the presence of the 2
>> different AssertionIDs.
>>
>> To locate the signer key we could either have a simple STR2 to a cert
>> in the wsse header, or to a 2nd saml assertion, also in the message,
>> containing the attestor's key.
>>
>> Please let me know what you think, since I am trying to make the
>> interop example as consistent as possible with the profile.
>>
>> Thanks,
>>
>> Rich
>>
>>
>>
>> -----Original Message-----
>> From: ronald.monzillo@sun.com [mailto:ronald.monzillo@sun.com] Sent:
>> Tuesday, January 27, 2004 1:55 AM
>> To: wss@lists.oasis-open.org
>> Subject: [wss] Groups - WSS-SAML-09.pdf uploaded
>>
>>
>> The document WSS-SAML-09.pdf has been submitted by ronald monzillo
>> (ronald.monzillo@sun.com) to the OASIS Web Services Security TC
>> document repository.
>>
>> Document Description:
>> SAML token Profile
>>
>> Update of STR ValueTypes to use URIs as apposed to Qnames (issue
>> 196). Changed use of STR to carry saml:AuthorityBinding element. Many
>> edits to examples, including change to Sender-Vouches example to user
>> STR Dreference Transfrom.
>>
>> Download Document:
>>
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/5177/WSS-SAML-
>>
>> 09.pdf
>>
>> View Document Details:
>> http://www.oasis-open.org/apps/org/workgroup/wss/document.php?documen
>> t_id=51
>>
>> 77
>>
>>
>> PLEASE NOTE: If the above links do not work for you, your email
>> application
>> may be breaking the link into two pieces. You may be able to copy
>> and paste
>> the entire link address into the address field of your web browser.
>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the
>> OASIS TC), go to
>>
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
>>
>> .
>>
>>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]