[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] SAML Token Brainstorming
I am sorry. I was confusing the Bearer method and the Sender Vouches method. AS a result some of my remarks were in error. I am a little confused about where we are exactly. I suggest we wait for the Netegrity proposal and take that as our point of departure. I for one am pleased not to be the document editor. I had been expecting to do that. Hal > -----Original Message----- > From: Ron Monzillo [mailto:ronald.monzillo@sun.com] > Sent: Wednesday, October 15, 2003 5:20 PM > To: Hal Lockhart > Cc: pmishra@netegrity.com; wss@lists.oasis-open.org > Subject: Re: [wss] SAML Token Brainstorming > > > > > Hal Lockhart wrote: > > >I am having trouble following some of the comments. Instead of point by > >point responses, let me try to address the issues I have seen raised. > > > > > >1. Signed Assertions. My assumption was that a WSS environment, > it would be > >common to pass around signed assertions and stick them in > messages. I wanted > >to exercise the various combinations of the pre-signed token with message > >signing and encryption as well as signing of the token by the initial > >sender. I figured that if we can do all these things w/o > breaking the issuer > >signature, than unsigned tokens should work fine. I would > propose that the > >issuer PK be agreed out of band, but that the receiver verify it > each time > >to make sure that it is still ok. > > > I'll try to capture what I was thinking when I wrote the comments I > think you > are referring to. > > In their simplest forms the 2 confirmation mechanisms differ in whether > or not the assertion must contain an authority signature, and whether the > sender must sign the assertion. > > Holder-of-key requires that the assertion contain an authority > signature and > that the sender sign the msg. The sender need not sign the assertions. > > Except for the special case described below, Sender-vouches requires > that the sender sign both the assertion and the msg. The authority need > not sign the asertion (although doing so allows the relying party > to verify that the authority has established the binding of attributes > to the subject). > > In the special case, where a sender-vouches assertion identifies a > confirmation > key (of an authority authorized vouching-sender other than the > subject) the > assertion must contain an authority signature, and the sender must sign > the msg. > In this case, the sender need not sign the assertion. This case looks > a lot like holder-of-key (to the relying party). > > When a relying party receives a signed, sender-vouches confirmed > assertion, > The relying party must look into the assertion to see if it identifies a > confirmation key, in which case its processing of the msg must proceed > very similarly to the way it would proceed for reciept of a holder-of-key > confirmed assertion. > > When a relying party receives an unsigned, sender-vouches confirmed > assertion, > it need not go fishing for an an authority identified > confirmation key, and > should expect to validate that both the msg and the assertion have been > signed > by the sender. > > By itself, the fact that the assertion is or is not signed need not change > the outcome of the simple sender-vouches case (as you indicated), but I > would > expect signing of the assertion to be an important que to the > relying party > with respect to it looking deeper into the assertion (for the identifier > of a confirmation key). > > >2. Encryption. What I had in mind for encryption was something > like scenario > >#3. Sign the request and encypt the response using the same PK. We could > >also encrypt the request using an out-of-band key, but I don't > feel strongly > >about that. Similarly, we could sign the response using a second > >holder-of-key assertion. > > > I may have this wrong, but I was also referring to scenario 3 (of > the first > interop) which I thought featured a signed and encrypted msg body. I > think your suggestion that we focus on encrypting the response, is > consistent with my concern that the sender of some encrypted content > needs to have a security token identifying a key known only to the target. > > To do request encryption, I thought we would more likely depend on > the X509 profile to pass an encrypted key, in which case, I > thought we would > likely reuse the encrypted key for the response. We could, for > response only > encryption, reuse the key from a SAML assertion (used to sign the request) > to define an encrypted key, if we think response only encryption > is an important use case. > > Is there any reason why it would be bad to demonstrate a sign and encrypt > scenario that synergized both the x509 and Saml token profiles? > > > > >3. I don't understand the comments about the relationship > between signing of > >the assertion by the issuer and sender vouches. Maybe, like > Irving, I just > >do not understand the semantics of sender vouches. I thought that it was > >just way for an authority to create a bearer token. This seems > orthagonal to > >the issue of some party changing the contents of the assertion. > > > > > I don't think I saw Irving's comments, but I tried to describe what I > understand > to be all the variations of sender-vouches in my answer to 1. In sender > vouches, the > sender and or an assertion authority may vouch for the contents of the > assertion. The sender always vouches for the binding or "presence of" > the subject wrt to the msg. > > >What have I forgotten? > > > >Hal > > > > > > > >>-----Original Message----- > >>From: Ron Monzillo [mailto:ronald.monzillo@sun.com] > >>Sent: Tuesday, October 07, 2003 2:15 PM > >>To: Hal Lockhart > >>Cc: wss@lists.oasis-open.org > >>Subject: Re: [wss] SAML Token Brainstorming > >> > >> > >>Hal, this looks good. > >>Some very intial comments on scenarios below > >> > >>Hal Lockhart wrote: > >> > >> > >> > >>>Here are some thoughts on the possible contents of a SAML Token Profile > >>>Interop. > >>> > >>>Token References > >>> > >>>The spec currently includes keyname, but I recall discussion > (at the SAML > >>>F2F?) to drop it. > >>> > >>>That gives us: > >>> > >>>1. Key Identifier > >>>2. Direct Reference > >>>3. Embedded Reference > >>> > >>>The spec defines the use of two Subject Confirmation Methods: > >>> > >>>1. Holder of Key > >>>2. Sender Vouches > >>> > >>>I suggest we pre-generate and sign the Assertions we use, > >>> > >>> > >>perhaps one sender > >> > >> > >>>vouches and two holder of key. > >>> > >>>It seems to make the most sense to me to send an SSO Assertion (AuntN + > >>>optional attributes) with Sender Vouches in the Security header. > >>> > >>>It makes sense to send an Assertion with an Attribute Statement > >>> > >>> > >>with Holder > >> > >> > >>>of Key and use the key for signature and/or encryption. Since we have > >>>already tested X.509, I propose we just use a naked PK. > >>> > >>>Among the prior Interop scenarios we have: > >>> > >>>1. send token in header > >>>2. sign body with key in token > >>>3. sign some token with key in token > >>>4. encrypt body with key in token > >>>5. encrypt some token with key in token > >>>6. combinations of the above > >>> > >>> > >>> > >>> > >>I noticed your suggestion that we pre-generate and SIGN the assertions. > >>I think we should focus on scenarios somwhere between your 2 and 3 that > >>demonstrate the use of the sender-vouches and holder of key to sign the > >>body. > >> > >>In the case of sender-vouches we should try an unsigned by the authority > >>aassertion and sign both the assertion and the msg body, because when > >>signed assertions are used: > >> > >>1. the holder of key and sender vouches mechanisms are very (as in too) > >>similar > >>[on the other hand, there is a variant of sender-vouches used for > >>transparent > >>impersonation with a confirmation key in which case the key > >>containing/identifying > >>assertion must be signed by the authority] > >> > >>2. signing the assertion as in 3 (but also the body as in 2) gives us a > >>chance > >>to demonstrate the use of the security token transform - which > >>was proposed > >>to support exactly this use case. > >> > >>As discussed on the call, we should discuss how encryption should be > >>integrated with the SAML token profile. I agree that a key in or > >>referenced > >>from a (holder-of-key) assertion could be used in the same manner that a > >>key in an x509 cert was used in our encryption scenarios. > >> > >>Ron > >> > >> > >> > >>>So, does everybody agree so far? > >>>Which combinations do people actually want to do? I sugest that 3 or 4 > >>>scenarios may be sufficient. Remember we can do different things on the > >>>request and response. > >>> > >>>Hal > >>> > >>> > >>>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_wor > >> > >> > >kgroup.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_wor kgroup.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]