[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]