Re: [sca-policy] Issue 32 revisited

[Mike Edwards <mike_edwards@uk.ibm.com>]

Ashok,

I find it strange to make the leap from
a statement that the server MAY authenticate itself to the
client to a statement that the server
MUST authenticate itself to the client.  I don't think this was
ever implied by the original wording
in the specification.

I can understand that on occasion, the
client will want the server to authenticate itself.  If this is the
case, it seems far far cleaner to create
a new intent which means just that.

So I would suggest:

serverAuthentication  = server
must authenticate itself to the client
clientAuthentication = client must authenticate
itself to the server (this is what we have today)

mutualAuthentication = a profile intent
that includes both clientAuthentication and serverAuthentication.

As for "authentication" meaning
different things when attached to the client side of a wire than it does
when
it is attached to the server side of
a wire - I could not agree less.  In each case, the intent informs
the infrastructure
that supports the wire (in particular
the binding) that it must carry the protocol involved in authentication.
 

Refining that into serverAuthentication
and clientAuthentication does not change this position, other than
refining the requirements on the infrastructure
- each requires some specific capabilities from the infrastructure
- they are likely to be similar but
different capabilities.


I am still curious to understand what
concrete policies you envisage for serverAuthentication.  I can see
a number
of such policies for clientAuthentication,
but for serverAuthentication, I don't find very much.

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	ashok malhotra <ashok.malhotra@oracle.com>
To:	sca-policy@lists.oasis-open.org
Date:	12/12/2008 23:36
Subject:	[sca-policy] Issue 32 revisited

---

Rich and I had a long talk about this and Rich unearthed
some history.

On Oct 22, 2007 Kaanu Joshi gave a number to this issue and said:
This is a requirement that was levied from the OSOA bindings WG:
SCA Policy should define an intent which enables a client to request 
that a server authenticate itself to the client, so that the client 
knows it can trust the server.
See http://lists.oasis-open.org/archives/sca-policy/200710/msg00083.html

The "authentication" intent that is currently defined in the
spec says

*/authentication /*– the authentication intent is used to indicate that
a client must authenticate itself in order to use an SCA service. 
Typically, the client security infrastructure is responsible for the 
server authentication in order to guard against a "man in the middle"
attack.

Rich and I read this to mean:  the client always authenticates itself
to the 
server and the server MAY authenticate itself to the client, although,
we admit,
that the MAY is our interpretation of the words and others may read them
differently.

So, it seems to us that if we tighten up the wording to say that the 
server MUST authenticate itself to the client
then we have mutual authentication, which is what the issue asks for.

But let's go another step. Consider a situation where a service and 
reference are wired together and both sides require the authentication
intent. To me, this means that the server authenticates itself to the 
client and the client authenticates to the server, These seem like 
different policies and so the policies would not match even though the
intents match. This may be a WS-Policy problem not a SCA problem


-- 
All the best, Ashok

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU