[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
Rich,
I will try to keep this high level.
We have been discussing impersonation formulations both wrt to sv and hok.
I think we agree on how to use hok when NOT doing impersonation (i.e. 2a).
For 2b (hok based impersonation), you view the current SAML core text which
defines the keyInfo used with hok as as precluding the use of keyInfo within
a hok confirmed SubjectConfirmation Element to carry a key that is NOT held
by the subject of the assertion.
You have proposed another formulation for this case, which I think
degenerates
to sv, as it depends on authorities NOT giving hok confirmed assertions
to unauthorized (by the authority) impersonators.
I prefer that the authorization of hok confirmed impersonators be
explicitly defined within the assertion, and that we correct the
language in SAML Core as appropriate to sustain this use model.
I raised this issuse at last week's SS TC FTF. I think there is the SS TC
will accept a less restrictive interpretation; especially since the hok
confirmation mechanism is not used by any of the existing SS TC
defined profiles.
We seem to be in agreement on the (1a) sv use case, in which the
attesting entity would include a reference to its key in
SubjectConfirmation,
and then sign the assertion and the msg content. This would be
a departure from what the profile currently requires, in that the
the reference to the subject assertion would move from
SignedInfo/Reference to Signature/KeyInfo. The attesting entity could
either sign the assertion (enveloped) within the assertion, or via a
data reference. The following diagram employs the data
reference approach, as it requires one less signature creation and
validation,
and seems to more easily generalize to support 1b.
+-----------------------------+
+------>| msg content |
| | +-----------------------------+
| | +-->| subj sv assn |<--+
| | | | subjconf attester keyInfo | |
| | | +-----------------------------+ |
| | +---| ds ref (subject+attributes) | |
| +-----------------------------+ |
+-------| ds ref (msg content) | |
+-----------------------------+ |
| sig key info |---+
+-----------------------------+
(1b) where the attesting entity is authoritative for the confirmation
key, but not for the other attributes of the subject seems to be the
remaining problematic case. I think your proposal for this case is
to separate the confirmation key binding (authorized by the attesting
entity) and the other subject attributes (authorized by the assertion
authority) into separate assertions. At least one other person at the
SS TC FTF also advocated this approach, and the more I think about
this, the more I also think it is the correct approach.
+--------------------------+
+------>| msg content |
| +--------------------------+
| +---->| subj sv assn |
| | | attr env sig |
| | +--------------------------+
| | +-->| subj sv assn |<--+
| | | | subjconf attester keyInfo| |
| | | +--------------------------+ |
| | +---| ds ref (subject) | |
| | +--------------------------+ |
| +-----| ds ref (attributes) | |
| +--------------------------+ |
+-------| ds ref (msg content) | |
+--------------------------+ |
| sig key info |---+
+--------------------------+
Does the preceding diagram accurately represent the 2 assertion
approach you are advocating (for 1b)?
How do you feel about the approach diagrammed for 1a?
Ron
Levinson, Richard wrote:
>Ron,
>
>My replies are interspersed below in response
>to your replies.
>
>Note: I have also truncated some of the earlier
>messages since this is now pretty much self-contained
>starting with your 4 use case scenarios which are now
>at the end.
>
>
>
>
>
>>-----Original Message-----
>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
>>Sent: Wednesday, February 04, 2004 3:02 PM
>>To: Levinson, Richard
>>Cc: 'wss@lists.oasis-open.org '
>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>
>>
>>
>>
>>Levinson, Richard wrote:
>>
>>
>>
>>>Ron,
>>>
>>>Based on your previous email and the phone conversation we
>>>had yesterday that clarified the use cases in the email
>>>I have done some thinking about the ws message structures
>>>we can use to support the 4 use cases. I have included
>>>a first cut at something I think might work, where the
>>>WS Sig KeyInfo always points to an assertion whose subject
>>>is the invocation identity. The structures below incorporate the
>>>suggestions both of us have had in the course of these
>>>
>>>
>>discussions and
>>
>>
>>>are meant to be a structure within which we can define the
>>>
>>>
>>context of
>>
>>
>>>the use cases and the assertions and signatures necessary to support
>>>those use cases. Also, the main focus here is probably 2b with the
>>>other use cases leading up to it to provide a common context.
>>>
>>>Below are some defns and some use case scenarios that show the
>>>ws/saml message structures that can support those scenarios.
>>>
>>> Definitions:
>>>
>>> confirmation key: used to verify the signature on the
>>> message content.
>>>
>>> SAML Assertion Authority (saa)
>>>
>>> attr assertion: an assertion issued by the saa that contains
>>> some attributes that refer to the assertion subject.
>>> Basically the attester gets attr assertions from
>>> the saa.
>>>
>>> subject, attester, saa, recipient are set up as follows:
>>>
>>>
>>> +-------> saa
>>> | ^
>>> | |
>>> V V
>>> subject -> attester -> recipient
>>>
>>> In general, the subject gets authenticated by the saa and
>>> uses that authentication to interact with the attester in
>>> order to deliver messages to the recipient.
>>>
>>>The key is where the Security/Signature/KeyInfo STR (SSK STR) points.
>>>
>>>In all cases, we presume that subject has established identity
>>>relationship with saa and passes an indicator, such as a
>>>
>>>
>>saml artifact
>>
>>
>>>to the attester to give the attester ability to contact the
>>>
>>>
>>saa to get
>>
>>
>>>assertion related to subject. Also, in all cases the
>>>
>>>
>>attester creates
>>
>>
>>>the ws signature.
>>>
>>>The key difference between 1* and 2* is that for 1* the
>>>
>>>
>>recipient would
>>
>>
>>>rely on a business agreement with the attester for the purpose of
>>>dispute resolution, and in the 2* case the recipient would rely on a
>>>business agreement with the saa for the purpose of dispute
>>>
>>>
>>resolution.
>>
>>
>>>In 2* the attester basically acts as an authorized agent of
>>>
>>>
>>the saa to
>>
>>
>>>receive messages from users, get an assertion describing
>>>
>>>
>>that user and
>>
>>
>>>packaging up a ws message that is sent to the recipient.
>>>
>>>
>>>1. attesting entity is authoritative for defining the confirmation
>>> key and confirms its knowledge of the key.
>>>
>>> a. the attesting entity is also authoritative for the
>>> contents of the assertion
>>>
>>>1a. attester and saa are the same entity. SSK STR points to
>>>
>>>
>>sv assertion
>>
>>
>>> in message. Assertion contains attester signature with
>>>
>>>
>>verification
>>
>>
>>> key for both the assertion and the content. Recipient relies
>>> on attester.
>>>
>>>
>>> +-------------------+
>>> | content |<-+
>>> +-------------------+ |
>>> | subj sv/attr assn | |
>>> +->| attester env sig | |
>>> | +-------------------+ |
>>> | | ws sig ref |--+
>>> | +-------------------+
>>> +--| ws sig key info |
>>> +-------------------+
>>>
>>>
>>>
>>Rich,
>>
>>In the preceding example, I presume the attester is putting a
>>reference
>>to its key
>>somewhere. I guess that key could be in the "attester env sig", or it
>>could be
>>in the assertion subject conf. I am guessing it would be easier to
>>find/recognize if it
>>is in subject conf, but I am not sure. Moving the attester's
>>key to the
>>signature, would
>>likely open up furthur simplification, as I'll try to depict below:
>>
>>1a.
>>
>> +-------------------+
>> | content |<---+
>> +-------------------+ |
>> +--->| subj sv assn | |
>> | | attester env sig | |
>> | | env sig keyValue | |
>> | +-------------------+ |
>> | | ws sig ref |----+
>> | +-------------------+
>> +----| ws sig key info |
>> +-------------------+
>>
>>
>
>My intent was that the attester signature on the assertion
>would implicitly contain the attester key. I do not see any
>necessity to put it in the SubjectConfirmationData since
>standard signatures already have the KeyInfo in place. We
>can decide later exactly how the KeyInfo references the
>key, but I think that is almost application-specific since
>XML signatures provide a wide variety of acceptable techniques.
>Also, since this is a signature enveloped in a saml assertion
>it does not really need to branch back out into the
>WS-Security layer to use SecurityTokenReferences, but that,
>of course, is an option if the application chooses to do it.
>
>
>
>>1b. done with 2 signatures in assertion is depicted below and
>>would require a change to the SAML schema to allow multiple
>>signatures in assertions. This approach would suggest that
>>the signers of the assertion that is also signing the msg
>>content is attesting for the subject in the context of the
>>msg. This approach would depend on the receiver being able to
>>tell which signature contains the key that it should use to
>>validate the signature on the
>>msg content. One simple hueristic might be to expect the
>>attestor signature to be that last one added to the assertion
>>
>> +-------------------+
>> | content |<---+
>> +-------------------+ |
>> +--->| subj sv assn | |
>> | | saa env sig | |
>> | | saa sig keyValue | |
>> | | attester env sig | |
>> | | env sig keyValue | |
>> | +-------------------+ |
>> | | ws sig ref |----+
>> | +-------------------+
>> +----| ws sig key info |
>> +-------------------+
>>
>>As I understand your suggestion for 1b (below), you help the
>>receiver understand which signature is which, by separating
>>them in different assertions;
>>.one attester signed assertion naming the subject and
>>demonstrating the attestor key .one saa and attesting entity
>>signed (in different ways) assertion containing the
>>attributes of the subject (and bound by the attesting entity
>>to the msg content).
>>
>>
>>
>
>I had a couple of intents here. One was to avoid doing anything
>that would require changes to the saml specs, such as using
>a 2nd signature in the saml assertion.
>
>I don't think that multiple assertions is a problem since the
>recipient can just look thru the message and find what they
>want among the signed parts, basing their trust on the attester's
>signature.
>
>The other intent was to make it clear for the recipient to know
>who was responsible for this message. In particular, by having
>the attester sign the contents of the saa assertion means the
>attester is responsible for the assertion at least as far as
>the recipient is concerned. In this sense it is optional whether
>the saa signs the attr assertion as far as the recipient is
>concerned, because the recipient has a primary agreement with
>the attester. There could be secondary agreements, of course,
>in which case the recipient could complain to the saa that it
>relied on its assertion in the attester context. But this would
>probably also require an agreement between the attester and saa
>to cover such situations.
>
>In general, I am trying to avoid any presumption about business
>agreements that need to exist, but am trying to set things up
>so any scenario conceivably could be set up between the recipient
>and 1 other party: the attester in the 1* cases, and the saa
>in the 2* cases.
>
>It appears to me that the 1b I suggested provides a framework
>that does not require any spec changes, supports a model that
>can be put into practice with a single business agreement, and
>is flexible enough to support multiple business agreements if
>that is what the parties want.
>
>
>
>
>>>1. attesting entity is authoritative for defining the confirmation
>>> key and confirms its knowledge of the key.
>>>
>>> b. The assertion issuer is authoritative for the contents of
>>> the assertion other than the confirmation key.
>>>
>>>1b. attester gets attr assertion from saa. Attester sig
>>>
>>>
>>covers both the
>>
>>
>>> assertion and the content. SSK STR points to sv assertion
>>> in message with same subject as attr assertion. Attester signs
>>> the sv assertion. Recipient relies on attester.
>>>
>>> +-------------------+
>>> | content |<---+
>>> +-------------------+ |
>>> | subj attr assn |<-+ |
>>> +-------------------+ | |
>>> | subj sv assn | | |
>>> +->| attester env sig | | |
>>> | +-------------------+ | |
>>> | | ws sig ref |--+ |
>>> | +-------------------+ |
>>> | | ws sig ref |----+
>>> | +-------------------+
>>> +--| ws sig key info |
>>> +-------------------+
>>>
>>>
>>>2. assertion issuer is authoritative for defining the confirmation
>>> key and attesting entity confirms knowledge of key.
>>>
>>> a. issuer establishes confirmation key such that only the
>>> subject of the assertion can satisfy the confirmation
>>> method.
>>>
>>>2a. attester and subject are the same entity. This is pure
>>>
>>>
>>holder-of-key
>>
>>
>>> case. Subject gets hk assertion from saa. Subject uses
>>>
>>>
>>private key
>>
>>
>>> to create sig w SSK STR pointing to hk assertion.
>>>
>>>
>>Recipient relies
>>
>>
>>> on saa.
>>> (this should represent section 3.4.1.3 in WS-SAML Profile V9)
>>>
>>> +-------------------+
>>> | content |<-+
>>> +-------------------+ |
>>> | attester hk assn | |
>>> +->| saa env sig | |
>>> | +-------------------+ |
>>> | | ws sig ref |--+
>>> | +-------------------+
>>> +--| ws sig key info |
>>> +-------------------+
>>>
>>>
>>>
>>>2. assertion issuer is authoritative for defining the confirmation
>>> key and attesting entity confirms knowledge of key.
>>>
>>> b. issuer establishes confirmation key such that entities other
>>> than the the subject of the assertion can satisfy the
>>> confirmation method (i.e are authorized to impersonate the
>>> subject).
>>>
>>>2b. attester is authorized by saa to impersonate subjects
>>>
>>>
>>for whom it
>>
>>
>>> supplies assertions. Attester gets attr assertion signed by saa
>>> with saa attributes referring to subject. Attester signs
>>> sv assertion with same subject as attr assertion.
>>>
>>> How does SSK STR point to subject in 2b? Attester could sign
>>> sv assertion with sig that has KeyInfo that points to
>>> attester hk assertion, signed by saa.
>>>
>>> Recipient relies on saa.
>>>
>>> (this should represent section 3.4.2.3 in WS-SAML Profile V9,
>>> except that instead of the WS-KeyInfo pointing to an hk
>>>
>>>
>>assertion
>>
>>
>>> it points to an sv assertion signed by the attester, which has
>>> a pointer to an hk assertion signed by the saa. Also rather than
>>> have ref 1 point to an str to an off message sv assertion, ref 1
>>> points to an onboard sv attr assn signed by the saa )
>>>
>>> +-------------------+
>>> | content |<---+
>>> +-------------------+ |
>>> | subj attr assn |<-+ |
>>> | saa env sig | | |
>>> +-------------------+ | |
>>> | subj sv assn | | |
>>> +--->| attester env sig | | |
>>> | +--| attester key info | | |
>>> | | +-------------------+ | |
>>> | | | attester hk assn | | |
>>> | +->| saa env sig | | |
>>> | +-------------------+ | |
>>> | | ws sig ref 1 |--+ |
>>> | +-------------------+ |
>>> | | ws sig ref 2 |----+
>>> | +-------------------+
>>> +----| ws sig key info |
>>> +-------------------+
>>>
>>>
>>>
>>>
>>Focusing on your proposed 2b formulation, I can see that the
>>saa is authorizing the contents of the first assertion (i.e.
>>the attributes that pertain to the subject), and the key
>>binding of the attester (in the third assertion).
>>
>>I don't see how the saa is authorizing the impersonation
>>of the subject of the first and second assertions, by the
>>subject of the third assertion.
>>
>>It would seem that the second assertion would need to be
>>signed by the saa for this to be the case.
>>
>>Maybe you can clarify this.
>>
>>
>>
>
>My thinking on this is that by the saa granting an hk assertion
>to the attester, the saa is implicitly allowing the attester
>to use the attester key to sign messages. In particular,
>the saa is authorizing the attester to sign sv assertions
>containing subjects for whom the attester has acquired an attr
>assertion from the saa by means of the artifact the subject
>sent to the attester.
>
>The action of the attester would be after acquiring the attr
>assertion for the subject from the saa, the attester would
>create a simple sv subject assertion identifying the same
>subject, and the signature on the sv assertion would point to
>the attester hk assertion which it got from the saa to authorize
>such actions.
>
>When the recipient gets the message, the recipient looks to the
>ws sig key info to find the confirmation key and the invocation
>identity which is the subject. The ws key info points the recipient
>to the subj sv assn to get the subject. The assertion is signed
>by the attester, and the KeyInfo of that sig points to the hk
>assertion which contains the attester key authorized by the saa.
>
>The net of this, I think, is that the attester effectively becomes
>an authorized agent of the saa. And for the purposes of business
>agreements the recipient would deal with the saa and the attester
>could recede to be simply a pretty much transparent intermediary
>subject to controls by the saa.
>
>
>
>
>>Drawing a similar diagram for what the STP currently
>>profiles, the formulation would look as follows:
>>
>> +-------------------+
>> | content |<---+
>> +-------------------+ |
>> +--->| subj hk assn | |
>> | | subConf keyInfo |--+ |
>> | | saa env sig | | |
>> | +-------------------+ | |
>> | | attester hk assn |<-+ |
>> | | subConf keyValue | |
>> | | saa env sig | |
>> | +-------------------+ |
>> | | ws sig ref |----+
>> | +-------------------+
>> +----| ws sig key info |
>> +-------------------+
>>
>>which is a variation of the non-impersonation hok case (as
>>currently profiled). The variation is that an assertion of
>>the attesting enity would be referenced from the subject assertion.
>>
>> +-------------------+
>> | content |<---+
>> +-------------------+ |
>> +--->| subj hk assn | |
>> | | subConf keyValue | |
>> | | saa env sig | |
>> | +-------------------+ |
>> | | ws sig ref |----+
>> | +-------------------+
>> +----| ws sig key info |
>> +-------------------+
>>
>>Ron
>>
>>
>>
>
>The problem I see with these formulations is that subject assertion
>is an hk assertion, but the content is signed by the attester
>who is not the subject. As I understand the 2b reqt:
>
> b. issuer (< saa, I assume >) establishes confirmation key such
> that entities other than the subject (< the attester, I
> assume is the "entity other than the subject" >) of the
> assertion can satisfy the confirmation method (i.e are
> authorized to impersonate the subject).
>
>I interpret this to mean that attester has the confirmation key
>and that the subject does not need to enter a key into this
>scenario, i.e. this is what sender-vouches is intended for.
>And the subject could initiate this scenario with an artifact
>from a browser.
>
>Also the Saml binding spec section 5.1 says this about holder of
>key:
>
> "The subject of the assertion is the party that can
> demonstrate that it is the holder of the key."
>
>I interpret this to mean that subject should be the one showing
>they have possession of a particular key, but it is the attester,
>I believe, that is doing the signing in 2b.
>
>Maybe there is still some context here that I am missing, which would
>not surprise me since I suspect there are several possible ways that
>these reqts might be interpreted and met.
>
> Rich
>
>
>
>
>
>>>Let me know if you think this moves us closer to a
>>>framework that captures the requirements.
>>>
>>> Thanks,
>>>
>>> Rich
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM]
>>>>Sent: Monday, February 02, 2004 1:24 PM
>>>>To: Levinson, Richard
>>>>Cc: 'wss@lists.oasis-open.org '
>>>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
>>>>
>>>>
>>>>
>>>>Levinson, Richard wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Ron,
>>>>>
>>>>>I have reviewed the rest of your comments and I believe
>>>>>we are in basic agreement on the principles involved,
>>>>>and what it really boils down to is how to implement
>>>>>
>>>>>
>>>>>
>>>>>
>>>>sender-vouches in
>>>>
>>>>
>>>>
>>>>
>>>>>a recognizable and efficient manner.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Rich,
>>>>
>>>>Sounds good.
>>>>
>>>>As I mentioned a few msgs ago, it is difficult with sv, to
>>>>set things up such that the attesting entity is authoritative
>>>>for the key binding, but not for the other contents of the
>>>>assertion. Maybe your proposed use of the assertion
>>>>signature, opens up a new way to accomplish this.
>>>>
>>>>IMO, the important (msg authentication) use cases are as follows:
>>>>
>>>>1. attesting entity is authoritative for defining the
>>>>confirmation key and
>>>> confirms its knowledge of the key.
>>>> a. the attesting entity is also authoritative for the
>>>>
>>>>
>>contents of
>>
>>
>>>>the assertion
>>>> b. The assertion issuer is authoritative for the
>>>>
>>>>
>>contents of the
>>
>>
>>>>assertion
>>>> other than the confirmation key.
>>>>
>>>>2. assertion issuer is authoritative for defining the
>>>>confirmation key
>>>>and attesting
>>>> entity confirms knowledge of key.
>>>> a. issuer establishes confirmation key such that only the
>>>>subject of
>>>>the assertion
>>>> can satisfy the confirmation method.
>>>> b. issuer establishes confirmation key such that entities
>>>>other than
>>>>the
>>>> the subject of the assertion can satisfy the
>>>>
>>>>
>>confirmation method
>>
>>
>>>>(i.e are authorized
>>>> to impersonate the subject).
>>>>
>>>>Maybe there should also be variants of both 2a, and 2b, that
>>>>allow the
>>>>subject
>>>>of the assertion to be authoritative for some or all of the
>>>>
>>>>
>>assertion
>>
>>
>>>>content
>>>>except the definition of the confirmation key.
>>>>
>>>>Any comments on the use cases?
>>>>
>>>>I suspect if we settle on use cases, it will be easier for us
>>>>to improve the related profile specific details.
>>>>
>>>>BTW, the SAML schema doesn't seem to allow multiple
>>>>signatures to be included in the assertion. If it did, maybe
>>>>the "difficult" sv case I noted above, which is case 1b in
>>>>the list of use cases, could be handled (in the signature
>>>>approach you proposed) by the attesting entity adding a
>>>>second signature to the assertion (using its key as keyInfo).
>>>>
>>>>Independent of how many signatures there are in the
>>>>assertion, the receiver of a sv confirmed assertion would
>>>>have to understand that the msg signature key must be a key
>>>>used to create a signature (within the assertion).
>>>>
>>>>I think the signature approach is interesting, but if we
>>>>accept the use cases enumerated above, I think we should
>>>>think a bit harder about how we might allow an attesting
>>>>entity, other than the assertion issuer, to authorize one or
>>>>more confirmation keys in subject confirmation.
>>>>
>>>>I realize that doing this would call into question SAML's
>>>>definition of KeyInfo in SubjectConfirmation, where the
>>>>identified key is supposed to be "held by the subject".
>>>>
>>>>
>>>>Ron
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>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/leav
>>>>>
>>>>>
>>>>>
>>>>>
>>>>e_workgrou
>>>>
>>>>
>>>>
>>>>
>>>>>p.php.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>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/leav
>>>
>>>
>>e_workgrou
>>
>>
>>>p.php.
>>>
>>>
>>>
>>>
>>>
>
>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]