RE: Comments on draft 0.7a S2ML specification

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

> Linking the assertion via a URI (rather than cryptographically 
> to a message stream, or to a key held by the entity
> authenticated by the name assertion) could leave the overall 
> scheme subject to IP- (or DNS-) level spoofing, depending on how 
> the URIs are constructed.
>
> The S/MIME binding in Sec. 6.2, in contrast, appears to apply a signed
> binding between the assertion, entitlements, and an actual 
> document, an approach which would avoid this risk.  I'd be interested to 
> understand the rationale for this apparent divergence between 
> the bindings for the different communications environments.


I agree that packaging of S2ML security documents into the
various bindings should be as consistent as possible. The 
messaging bindings (S/MIME, ebXML (which is in-progress), and
SOAP) should and can have this packaging consistency, preferably
along the lines of tyhe MIME binding approach which is generic
enough for being applied to ebXML and possibly SOAP. We'll have 
to fix that in the next rev. 

I'll leave someone else to comment on the HTTP binding, except
that there is discussion in section 5.2 pertaining to scoped
assertions and point-to-point integrity of transmitted data
over SSL.

thanks,
Zahid

 



Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: zahid.ahmed@commerceone.com
v:   (408)-517-3903



> -----Original Message-----
> From: Karl Best [mailto:karl.best@oasis-open.org]
> Sent: Friday, January 05, 2001 9:15 AM
> To: security-services@lists.oasis-open.org
> Subject: FW: Comments on draft 0.7a S2ML specification
> 
> 
> (Manually forwarded from the public comments list; I'll get 
> the auto-forward
> fixed soon.)
> 
> </karl>
> 
> 
> -----Original Message-----
> From: Linn, John [mailto:jlinn@rsasecurity.com]
> Sent: Wednesday, January 03, 2001 3:26 PM
> To: 'security-services-comment@lists.oasis-open.org'
> Subject: Comments on draft 0.7a S2ML specification
> 
> 
> I'd like to offer a few comments on the v0.7a S2ML document. 
> Generally, I
> think that it embodies many good goals and useful ideas, but 
> believe that
> some aspects may be in need of refinement or further 
> specification.  The
> goals of independence from particular authentication and authorization
> schemes are good. The notion of using a PK-based signing 
> authority to sign a
> name assertion, vouching for an identity which may have been 
> authenticated
> by a variety of authentication systems, is a good unifying principle.
> 
> The idea of providing means to represent authorization 
> queries and return
> results in response to those queries is a valuable and 
> important function,
> though one which has historically been difficult to standardize.
> Extensibility in this area (as is provided, e.g., for the entitlement
> contents) seems particularly important.
> 
> I'm wondering about a couple of aspects related to 
> authentication requests.
> Page 15 specifically places challenge-response protocols 
> outside scope for
> v1.0.  Nonetheless, it seems likely that support for 
> iterated, multi-step
> user authentication transactions will be needed at some 
> point; it may make
> sense to anticipate this need with some form of continuation 
> hook in the
> request and response messages which carry authentication transactions.
> 
> For AuthRequests with PKI Credentials, it's clear how a 
> public key or name
> can be identified, but some other element (either in 
> Credentials or external
> to it) may need to be defined with which a requestor can 
> demonstrate that it
> possesses the corresponding private key, thereby accomplishing the
> verifiable authentication.
> 
> Functionally, the cryptographic construction discussed in 
> Sec. 6.1 for the
> HTTP binding seeks to bind a sender ID (URI) to an assertion object
> reference, in a manner that is transferable among a set of 
> sites sharing a
> common AES key.  Linking the assertion via a URI (rather than
> cryptographically to a message stream, or to a key held by the entity
> authenticated by the name assertion) could leave the overall 
> scheme subject
> to IP- (or DNS-) level spoofing, depending on how the URIs 
> are constructed.
> The S/MIME binding in Sec. 6.2, in contrast, appears to apply a signed
> binding between the assertion, entitlements, and an actual 
> document, an
> approach which would avoid this risk.  I'd be interested to 
> understand the
> rationale for this apparent divergence between the bindings for the
> different communications environments.
> 
> --John Linn, RSA Laboratories
>