OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-sx] Issue 100: Lack of Rationale for choices of Authentication for WS-SC operations


Thanks Tony. Security context signature required over additional  
claims is different than wording I suggested, so I see your point.

I am ok with what you have in the red-line doc.

regards, Frederick

Frederick Hirsch
Nokia


On Sep 5, 2006, at 6:49 PM, ext Anthony Nadalin wrote:

> Not sure I agree with update as you changed the wording and meaning,
>
> >by providing signatures using keys associated with those claims
>
> Not all claims will have keys
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> <graycol.gif>
> Frederick Hirsch <frederick.hirsch@nokia.com>
>
>
> Frederick Hirsch <frederick.hirsch@nokia.com>
> 09/05/2006 05:41 PM
>
> <ecblank.gif>
>
> To
> <ecblank.gif>
>
> ext Chris Kaler <ckaler@microsoft.com>
> <ecblank.gif>
>
> cc
> <ecblank.gif>
>
> Frederick Hirsch <frederick.hirsch@nokia.com>, "ws-sx@lists.oasis- 
> open.org" <ws-sx@lists.oasis-open.org>
> <ecblank.gif>
>
> Subject
> <ecblank.gif>
>
> Re: [ws-sx] Issue 100: Lack of Rationale for choices of  
> Authentication for WS-SC operations
> <ecblank.gif>
> <ecblank.gif>
>
> minor revision, inline
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Sep 1, 2006, at 4:36 AM, ext Chris Kaler wrote:
>
> > Any other comments on 100 or do people feel good about this?
> >
> >
> >
> > I haven’t seen any further discussion on the 108/109 proposals –
> > are people OK with them?
> >
> >
> >
> > Can the editors pull together and post a parallel copy with these
> > three edits rolled in so that folks have a chance to review before
> > Wed.  That way if the TC is OK with the edits we can have the CD/PR
> > votes without any open Trust/SC issues.
> >
> >
> >
> > If there are issues with 100/108/109 please post so that we can try
> > to address them before the Wed call.
> >
> >
> >
> > Thanks,
> >
> > Chris
> >
> >
> >
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Sent: Thursday, August 31, 2006 1:03 PM
> > To: Jan Alexander; Marc Goodner; ws-sx@lists.oasis-open.org
> > Subject: RE: [ws-sx] Issue 100: Lack of Rationale for choices of
> > Authentication for WS-SC operations
> >
> >
> >
> > This looks good to me.
> >
> >
> >
> > Hal
> >
> >
> >
> > From: Jan Alexander [mailto:janalex@microsoft.com]
> > Sent: Tuesday, August 29, 2006 9:32 PM
> > To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org
> > Subject: RE: [ws-sx] Issue 100: Lack of Rationale for choices of
> > Authentication for WS-SC operations
> >
> >
> >
> > Hal,
> >
> >
> >
> > Here is my proposal that adds more rationale and explicitness to
> > the required authentication description for WS-SC operations to
> > address this issue:
> >
> >
> >
> > Change Amend authentication requirements on lines 519-521 as  
> follows:
> >
> >
> >
> > Proof of possession of the key associated with the security context
> > MUST be proven in order for context to be amended. It is
> > RECOMMENDED that the proof of possession is done by creating a
> > signature over the message body and key headers using the key
> > associated with the security context.
> >
> >
> >
> > Additional claims to amend the security context with MUST be
> > indicated by providing signatures over the security context
> > signature created using the key associated with the security
> > context. Those additional signatures are used to prove additional
> > security tokens that carry claims to augment the security context.
> >
> >
>
> Additional claims that amend the security context MUST be indicated
> by providing signatures using keys associated with those claims, each
> signing over the security context signature. Those additional
> signatures are used to prove possession of the additional security
> tokens that carry claims to augment the security context.
>
> > Change Renew authentication requirements on lines 590-595 as  
> follows:
> >
> >
> >
> > A renewal MUST include re-authentication of the original claims
> > because the original claims might have an expiration time that
> > conflicts with the requested expiration time in the renewal
> > request. Because the security context token issuer is not required
> > to cache such information from the original issuance request, the
> > requestor is required to re-authenticate the original claims in
> > every renewal request. It is RECOMMENDED that the original claims
> > re-authentication is done in the same way as in the original token
> > issuance request.
> >
> >
> >
> > Proof of possession of the key associated with the security context
> > MUST be proven in order for security context to be renewed. It is
> > RECOMMENDED that this is done by creating the original claims
> > signature over the signature that signs message body and key  
> headers.
> >
> >
> >
> > During renewal, new key material MAY be exchanged. Such key
> > material MUST NOT be protected using the existing session key.
> >
> >
> >
> > Change Cancel authentication requirements on lines 675-676 as  
> follows:
> >
> >
> >
> > Proof of possession of the key associated with the security context
> > MUST be proven in order for security context to be cancelled. It is
> > RECOMMENDED that this is done by creating a signature over the
> > message body and key headers using the key associated with the
> > security context.
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Wednesday, August 09, 2006 6:15 AM
> > To: Hal Lockhart; ws-sx@lists.oasis-open.org
> > Subject: [ws-sx] Issue 100: Lack of Rationale for choices of
> > Authentication for WS-SC operations
> >
> >
> >
> > Issue 100.
> >
> >
> >
> > -----Original Message-----
> >
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> >
> > Sent: Monday, August 07, 2006 1:50 PM
> >
> > To: ws-sx@lists.oasis-open.org
> >
> > Cc: Marc Goodner
> >
> > Subject: NEW Issue: Lack of Rationale for choices of Authentication
> > for WS-SC operations
> >
> >
> >
> >
> >
> > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD
> > UNTIL THE ISSUE IS ASSIGNED A NUMBER.
> >
> > The issues coordinators will notify the list when that has occurred.
> >
> >
> >
> > Protocol:  ws-sc
> >
> >
> >
> > http://www.oasis-open.org/committees/download.php/18840/ws-
> > secureconvers
> >
> > ation-1.3-spec-ed-01-r06-diff.pdf
> >
> >
> >
> > Artifact:  spec
> >
> >
> >
> > Type: design
> >
> >
> >
> > Title:
> >
> >
> >
> > WS-SC defines 4 operations: Issue, Amend, Renew and Cancel.
> >
> >
> >
> > In the case of Amend, WS-SC does not specify what Authentication is
> > required. In the case of Renew, it says the original claims must be
> > re-authenticated. If the SCT has expired, its key must not be used
> > to authenticate. The examples for Amend and Renew both show
> > signatures which use both the long term Token and the SCT.
> >
> >
> >
> > In the case of Cancel, WS-SC says that the client must provide PoP
> > of the SCT secret. The example shows only one signature, which uses
> > the SCT.
> >
> >
> >
> > It is not clear a) the reason for these choices and b) why they are
> > all different.
> >
> >
> >
> >
> >
> > Description:
> >
> >
> >
> > For Amend and Renew, it seems to me that the Principle of Perfect
> > Forward Secrecy suggests that the long term Identity be used in all
> > these cases to authenticate the client. That way if the SCT secret
> > is compromised, the request will still be protected. (If the long
> > term secret is compromised, all bets are off anyway.)
> >
> >
> >
> > Also I don't understand why a Cancel requires specifically PoP of
> > the SCT secret.
> >
> >
> >
> > Related issues:
> >
> >
> >
> > 78
> >
> >
> >
> > Proposed Resolution:
> >
> >
> >
> > Rationalize the choices and provide rationale for them.
> >
> >
> >
> > Hal
> >
> >
> >
> >
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]