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