[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
If the latter is the case, then the question is when you shed the SAML wrapper for the signing key and use the X.509 wrapper. My inclination has been that since there are not yet any widely accepted SAML authorities, that common practice would generally end with an X.509 root. Assuming that to be the case, then the rest of the issues are kind of distinguishing between the 2 layer: subject plus "attester/assertion authority" where the subject is wrapped in an assertion and the a/aa uses an X.509 cert to end the chain; and the 3 layer: subject plus attester plus assertion authority, where now both the subject and attester would have saml assertions and the aa would use an X.509 cert. If we assume a trusted root saml authority then possibly the X.509 cert in the above scenarios would be replaced by a root saml assertion. In these scenarios, the invocation identity is always the subject of the assertion, and the sender-vouches use case is determined by the fact that the recipient follows the Signature/KeyInfo and first encounters the sender-vouches assertion, which I am assuming, as suggested in my previous email is a signed assertion with an enveloped signature signed by the attester. Rich > -----Original Message----- > From: Levinson, Richard > Sent: Sunday, February 01, 2004 10:29 AM > To: 'Ron Monzillo '; Levinson, Richard > Cc: 'wss@lists.oasis-open.org ' > Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded > > > > Ron, > > I am responding to your up front comment and > will look at the other comments tomorrow. > > As I understand what you are saying, you would > prefer that the Signature/KeyInfo always point > to a token containing the invocation identity. > > Although I had not looked at it from quite this > perspective, I agree that the sender-vouches as > currently construed has some questionable > characteristics. > > I think this arises from a basic shortcut that > is taken in the scenario which is having one > signature sign both the assertion and the message. > This saves time by only having one signature to > create but as you have indicated it starts to open > up all other sorts of issues. One that has always > troubled me is that it kind of breaks the atomicity > of the assertion token, such that the assertion is > not valid outside the context of the message. Also, > it puts the path to the invocation identity in > a Signature/Reference rather than a Signature/KeyInfo. > > In my opinion, the way this should be set up is that > the attester should first sign the assertion, and in > effect become the assertion authority (using an > enveloped signature), then sign the message using > standard WS practice, with the Signature/KeyInfo > pointing to the assertion. > > This way the recipient can obtain the invocation > identity from the token pointed to by Signature/KeyInfo. > > Authentication then becomes a degenerate case of the > holder-of-key authentication, where the "holder-of-key" is > now effectively also the assertion authority/ attester. > > From the recipient's perspective the sender-vouches > distinction indicates that the invocation identity is > not the signer. In the hk case the invocation identity > is the signer. > > This approach allows one assertion to contain all the > necessary information, at the expense of 2 signatures > required by the attester: one to sign the assertion which > contains the invocation identity as subject of assertion, and > one to sign the message to bind it to the invocation > identity. The recipient, by trusting the signing key of the > attester now simply has to verify 2 signatures which happen > to be signed by the same signer. In the hk case 2 sigs also > need to be verified by the recipient by different signers > chained thru the SubjectConfirmation/KeyInfo. In the sv case > the chaining is implicit since the attester replaces the > subject as the signer of the content. > > The only loose end in all this I believe is a distinction > between the attester and the assertion authority. If this > level is required then we would have another level of > chaining, whereby we would need subject->attester->assertion > authority. In this case the assertion authority would need to > put the attester's key in an hk assertion as the current > example shows. The attester would then sign the sv assertion > as described above, and then sign the message. Since we now > have 3 levels involved, we need the 2nd hk assertion that the > recipient needs to confirm the attester, assuming the > recipient ultimately trust the assertion authority. > > Rich > > -----Original Message----- > From: Ron Monzillo > To: Levinson, Richard > Cc: wss@lists.oasis-open.org > Sent: 1/30/2004 7:06 PM > Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded > > > > Levinson, Richard wrote: > > >Replies interspersed below (this discussion gets > >quite detailed, but I have made a sincere effort to > >try to stay on point and narrow rather than broaden > >the scope): > > > >Again, I think the bottom line is that using a BST to > >contain the attester cert in the sender-vouches scenario > >is a better (cleaner and simpler) option than using a 2nd > >saml assertion to contain the attester cert. > > > > > Rich, > > I expect to use sender-vouches approximately as follows: > > An attesting entity uses its key binding to secure a message > containing a request to invoke a web service. > > The identity(s) under which the web service is to be invoked > is represented in the subject statements of the > sender-vouches confirmed assertion. > > The holder of key confirmed security token of the attesting > entity carries the key used to sign the message, but the > receiver must be able to recogise that the vouched for > assertion contains the invocation identity. > > Whether or not the key confirmed security token used to sign > the message and assertion is itself a BST or a SAML > assertion, has little impact on the message reciever's > ability to recognize the proper invocation identity for the message. > > As the spec is currrently written, it is unclear how the the > msg receiver can establish the correspondence between the > SOAP msg and the vouched for subject statments. The only clue > that the receiver has that such a correspondence should be > established is the fact that SignedInfo references (i.e. > digests) a sender-vouches confirmed assertion. > > That is my point, and the reason why I suggested that proper > interpretation of impersonation scenarios, including those > accomplished using > sender-vouches > confirmed assertions could be more direct and consistent with > how other > profiles > establish what I refer to as the invocation identity, if > Signature/keyInfo (always) > points to a security token containing the invocation identity. In > non-impersonation > scenarios the signer and invocation identities are presumably > the same. > > I included other comments below, but I'd like to focus on the > representation of impersonation and its interpretation by > receivers. Sender vouches is on such formulation of which we > have been dicussing two different approaches; 1 curently in > the spec, and another based on chaining. > > Another form of impersonation would be assertion issuer authorized > assertion. > > >>-----Original Message----- > >>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] > >>Sent: Friday, January 30, 2004 12:49 PM > >>To: Levinson, Richard > >>Cc: wss@lists.oasis-open.org > >>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded > >> > >> > >> > >>Levinson, Richard wrote: > >> > >> > >> > > > > > > > > > >>>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): > >>> > >>> > >>> > > > > > > > > > >>Rich, > >> > >>Unless I am misunderstanding you, > >>This is what the example in the spec currently does, except > >>STR2 points to a SAML assertion acting as the attester cert, > >>and the sig ref points to the subject assertion and the sig > >>keyinfo points to STR2, and thus the attester cert. Other > >>than the example using only SAML ST's, I think it analogous > >>to what you propose. Maybe you are focusing on the token > >>combination we should demonstrate by interop. > >> > >> > >> > > > >Yes, functionally I guess it is equivalent. I was a little confused > >with the actual "sender-vouches" assertion not being shown > because it > >is externally accessed, and the on message assertion being > >holder-of-key. I understand it now but think that readers > who are not > >intimately familiar with all the options may have difficulty with it. > > > >And you are correct that I am focussing on putting together > >a self-contained scenario for the interop, and I think that > having the > >signature point to a 2nd saml assertion is not necessary since the > >recipient is trusting the public key of the signer/attester, not the > >fact that the public key is obtained in an assertion backed up by a > >trusted saml authority. My sense is that recipients will probably > >populate their key stores with certificates from well known issuers > >rather than self-generated certificates backed up by saml assertions. > >So, for the interop, I think I am going to go with the > >BinarySecurityToken as the holder of the attester cert. > > > I view a SAML holder of key confirmed assertion as an XML > certificate. The attesting entity could either use ists XML > certificate or its X509 XSN.1 certficate, they are logically > equivalent. > > >>Anyway, I think there is a problem with the existing > >>approach, especially when STR 2 does not either have a > >>"usage" attribute to inform the actions of the receiver. > >>Without such a cue, The receiver has to recognize that this > >>is a SAML profile msg, as aposed to an X509 profile msg, to > >>be able to properly determine the authentication identity > >>that should be associated with the msg. > >> > >> > >> > > > >If we use a BinarySecurityToken here, I think things are > >simplified since there is no ambiguity about identity of > >the attester. I think the main point of saml sender-vouches > >is that the attester is vouching for the subject of the > >saml assertion, and there is not really a need for the > >attester to also be represented by a saml assertion, and > >as you have shown that leads to issues regarding whether the > >requester is depending on the signer of the message or the > >authority that issued the saml assertion that contains > >the cert the attester used to sign the message. i.e. it > >seems to be implicitly forcing a chaining mechanism to > >be defined for saml assertions similar to certs which is > >not currently a practice to my knowledge. > > > I hope I clarified this above, I am interested in being able > to tell when the invocation identity should be the vouched > for subject. > > >>To do this, the receievr has to infer from the fact that a > >>SAML assertion was signed, and that its confirmation method > >>was satisfied, that the identity of the signed assertion > >>should be applied to the msg, as apposed to the identity > >>bound to the attester's security token; which if refactored > >>as you suggest would be an x509 cert. Such messages will > >>look a lot like conventional x509 confirmed msgs. The fact > >>that this is an impersonation scenario is not easy to recognize. > >> > >> > >> > > > >I'm not sure if I totally follow you here, especially the > phrase "the > >identity of the signed assertion should be applied to the > msg". I think > >what you are saying is from the receiver's point of view, who is > >actually accountable for this message. If that is the case, then the > >receiver needs to have a way to recognize the attester, and > this would > >be thru the attester's signing cert, which the receiver > would have in a > >key store and can be used to verify the signature on the message > >components. As I indicated above, if this cert is backed by a saml > >assertion rather than conventional PKI then we have kind of > a new use > >case that I think is outside of the current scope of common practice > >even in the saml domain. So, from that point of view I don't > think we > >would want the attester identity to be defined by the saml assertion > >but by the attester cert. > > > > > SAML assertions are perhaps a bit more flexible than x509 > identity certs, in that x509 identity certs typically need to > be long lived; but > other > than that, I try to view them as interchangeable. Maybe this > is an oversimplification on my part. > > >>> 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. > >> > >> > >>> > >>> > >>> > >>> > > > > > > > > > >>I was suggesting somnething like what you describe above, > >>leaving aside for the moment the ConfirmationData vs KeyInfo > >>distinction you have since made, as an alternative to what > >>is ]currently being done in the spec. I don't think we would > >>do both. This is sort of a backpointer to the cert of the > >>attesting entity, since > >>the front > >>pointer in the signature keyinfo is to the attester's cert. > >>The problem as I see it, is it is difficult for the receiver > >>to know when to apply SAML token profile semantics, unless > >>the front pointer points to a SAML assertion. > >> > >>At a high level, I was proposing that the KeyInfo reference > >>in the Signature point to a Subject assertion because it > >>would make it easy for the receiver to recognize that the > >>message was signed using the SAML token profile, and that the > >>indended authentication entity was the Subject of the > >>Assertion. This is already how we profile hold-of-key. > >> > >> > >> > > > >From my perspective the signature does not need to convey > any context > >about how the signature should be interpreted. It simply > signs message > >elements and it is up to the recipient what meaning to attach to the > >validity of such a signature. The fact that the KeyInfo in the sig > >leads to a saml assertion as currently in the profile spec does not > >imply anything about sender-vouches, it is just pointing to a key > >container. And, in fact, in the profile spec it actually points to a > >holder-of-key assertion. So, I think that if this points to a > >BinarySecurityToken instead will not impact any sender-vouches > >semantics. > > > > > The signature is being used to bind an identity to content; > aka to do data origin authentication. In the sender vouches > case, it is the vouched for identity that is being bound to > the content (by the attesting entity). > > >The sender-vouches semantics comes from the fact that the recipient > >after verifying the signature determines that one of the references > >signed by the signature is, in fact, a sender-vouches assertion, > > > My point is that it is hard for the receiver to recognize that it is > expected > to do this. > > >which in the current profile spec is off-message, but once > obtained by > >the receiver provides the context required to evaluate whether the > >message should be trusted or not. But the trust in the > message is not > >due to the fact that there is anything in particular about > the attester > >contained in the assertion, only the fact that it is a > sender-vouches > >assertion and that the attester signed it. > > > Actually I would expect the receivr to determine if it trusts > the attesting entity to vouch for the invocation identity. > > >Similarly, in the holder-of-key profile, the recipient again > trusts the > >assertion issuer's signature on the assertion (i.e. it is > the signer of > >the assertion who is trusted ultimately, not the subject of the > >assertion) which contains the holder-of-key's certificate > which in turn > >is used to verify the message content. > > > >Analytically, I believe the holder-of-key scenario > degenerates to the > >sender-vouches case if the holder-of-key also is the signer of the > >assertion. Sender-vouches then optimizes this by pulling the > assertion > >signature out of the assertion and combines it with the content sig. > > > > > > > >>>Furt2her, 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. > >>> > >>> > >>> > > > > > > > > > >>As noted above, unless I am missing something, and modulo the > >>substitution of a holder of key confimed assertion for the > >>BST, I think this is what the sender-vouches example in the > >>spec is currently demonstrating. > >> > >> > >> > > > >Yes, now that I see the structure with the off message > sender-vouches > >assertion, they are effectively the same. But as discussed above I > >think using STR2 to point to a 2nd saml assertion containing the > >attester's cert is raising some issues that don't appear to me to be > >critical path for smooth operability. In particular, if it is the > >attester cert that is ultimately trusted why go to the trouble of > >wrapping it in a saml assertion? Why not simply use a BST > and have that > >the end of the trust path? > > > > > The SAML assertion is the attester's certificate. In fact, in > the example we have been discussing, it contains the > attester's keyValue. > > > > > > >>I reading back through the thread, and I found a couple of > >>points that you raised that I think we should call attention to. > >> > >>1. As you point out, the SAML Core's description of KeyInfo > >>within SubjectConfirmation; precludes the use of this field > >>to specify a a key held by the attesting entity, not the > >>subject. This has come up before. We need to determine what > >>latitude we have in this area. IMO the SAML spec has been > >>overly prescriptive. I would prefer that it say something > >>like "that specifies a crytographic key held by an entity > >>authorized to act as the subject. > >> > >> > >> > > > >As discussed above I think that by using a BST for the > attester cert we > >can avoid dealing with this issue. > > > > > > > >>> An XML Signature [XMLSig] element that specifies a > >>> > >>> > >>cryptographic > >> > >> > >>> key held by the subject." > >>> > >>> > >>> > > > > > > > > > >>2. You point out that even if an assertion is signed, the attesting > >>entity must > >>sign it. I think you are concerned about the case of a signed > >>sender-vouches confirmed assertion without a contained and > >>protected key binding. In which case I agree the attesting > >>entity is defining the key binding, and this > >>must sign > >>the asertion and the message content. > >> > >> > > > >It sounds like we agree there. i.e. a signed assertion in > >and of itself does not protect anything but itself. In order > > > Yes, but the issue is whether it embodies an authority protected key > binding. > > >to bind such an assertion to external content, we have > >2 cases: sender-vouches whereby the attester signs both > >the assertion and the content, and holder-of-key where the signed > >assertion contains the holder-of-key's public key or cert and it is > >the holder-of-key's signature on the content that binds the > content to > >the assertion thru hk's public key bound in the assertion > which can be > >used to verify the content signature. > > > > > > > >>I am not sure how close to being on the same page we are, so > >>I hesitate to raise another problem, but it seems to me that > >>section 3.3.4 of of the > >>WSS STP, > >>"SAML assertion referenced from SubjectConfirmation" (by STR) > >>is prone to substitution problems, if the refererences do not > >>(at least) unambiguouly identify the intended security token. > >> > >>We defined the STR Dereference transform to be able to digest > >>assertion contents when they are referenced by STR, we would > >>likely need to require that a similar transform be applied in > >>the calculation > >>of the > >>signatures of assertions with STR's within > >>SubjectConfirmation/KeyInfo. > >> > >>I guess this could be argue against complex key references in > >>SubjectConfirmtion/KeyInfo. > >> > >> > >> > > > >As I mentioned in an earlier email my concern with 3.3.4 is that we > >have a potential infinite loop where the STR in the KeyInfo in the > >assertion points to the assertion itself, and we never > actually seem to > >find the key in question. > > > Maybe this could be a problem. > > I am concerned about the substitution properties of KeyInfo > inside SubjectConfirmation. > > Ron > > > > > Rich > > > > > > > >>Ron > >> > >> > >> > >>> Rich > > > >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]