[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded
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.
> >
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]