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 forWS-SC operations


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
Inactive hide details for Frederick Hirsch <frederick.hirsch@nokia.com>Frederick Hirsch <frederick.hirsch@nokia.com>


          Frederick Hirsch <frederick.hirsch@nokia.com>

          09/05/2006 05:41 PM


To

ext Chris Kaler <ckaler@microsoft.com>

cc

Frederick Hirsch <frederick.hirsch@nokia.com>, "ws-sx@lists.oasis-open.org" <ws-sx@lists.oasis-open.org>

Subject

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

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
>
>
>
>


GIF image



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