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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

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

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

Powered by eList eXpress LLC