If the editors could pull that together it
would save time if the votes pass. Thanks!
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Friday, September 01, 2006
5:54 AM
To: Chris Kaler
Cc: ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue 100:
Lack of Rationale for choices of Authentication for WS-SC operations
Yes will do so. Also do you want CD/PR Drafts created
for Wed ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Chris Kaler <ckaler@microsoft.com>
|
Chris
Kaler <ckaler@microsoft.com> 09/01/2006 03:36 AM |
|
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.
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