RE: [dss] Authentication (fixed typo - bad URL)

["Nick Pope" <pope@secstan.com>]

Trevor,

I believe for the case (3) below - Indirect via an authentication
authority - we cannot depend on lower layers.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 20 October 2003 22:02
> To: dss@lists.oasis-open.org
> Subject: [dss] Authentication (fixed typo - bad URL)
>
>
>
> The issue of how our protocol relates to client-authentication
> methods has
> come up.  In particular:
>   a) should these methods be relegated to the bindings, and not
> part of the
> protocol per se?
> *or*
>   b) should the protocol have some provision for sending
> tokens/assertions/etc. of some sort, and authenticating within
> the protocol
> itself.
>
> The requirements doc only says:
> """
>   3.10: Each binding may define authentication means (passwords, client
> certificates, etc.)
> """
>
> Which implies (a).  However, the doc was substantially rewritten for
> version 8.  Before then, the text was more ambiguous:
> """
> 1.1.1      Authentication
>
> 1) None (or by other means, such as TLS/SSL, IPsec)
> 2) Directly to the server within the protocol (e.g. WS-Security)
> 3) Indirectly via an Authentication Authority (e.g. SAML)
> 4) Combinations of above
> The protocol should be capable of supporting the above approaches
> to mutual
> authentication.  Bindings will fill in the details and mandate specific
> techniques.  The details of authentication techniques used to
> access a DSS
> server are not within the scope of this specification and there is no
> attempt by this specification to restrict such methods of authentication.
> """
>
> This text was taken pretty directly from a post by Robert:
> http://lists.oasis-open.org/archives/dss/200301/msg00032.html
>
> Anyways, I think the important point is (2) - does this mean (a) or
> (b)?  To me, it seems that WS-Security just another lower-layer
> "binding",
> so this leans toward (a).  But then why isn't (2) collapsed in (1)?
>
>
> I like (a) cause authentication usually isn't a matter of just sending a
> "token", usually you have to cryptographically sign something, or do some
> challenge-response, or whatever.  So I think we should rely on
> lower-level
> protocols to transfer these tokens and handle any cryptography/protocol
> aspects.
>
> We may need to "profile" these bindings - i.e., we may need to make a
> WS-Security profile that says what types of tokens are allowed, and how
> they should be used to sign the message.
>
> But I don't think we need to add anything to the core protocol to account
> for these, I think we can do the work later of figuring out how
> to utilize
> these lower layers.
>
>
> Trevor
>
>
>
>
>
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php.