RE: [wss] SAML Token Brainstorming

["Hal Lockhart" <hlockhar@bea.com>]

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
.