[Fwd: Interim requirements]

[Jeff Hodges <jhodges@oblix.com>]

---

• From: Philip Hallam-Baker <pbaker@verisign.com>
• To: "'security-core@lists.oasis-open.org'" <security-core@lists.oasis-open.org>
• Date: Mon, 22 Jan 2001 14:00:43 -0800

All,

	It is all very well to divide the document up into pieces and work
on each separately. However it is difficult to specify core architecture
without having any idea of the requirements at all.

	I think we need to begin with a bullet point list of the
requirements and constraints. We should probably start off with the full set
of all possible requirements and narrow from there. This will be driven by
the use cases in due course but should allow a start to be made on our
piece. In any case I suspect that our requirements will be considerably more
formal and technical that the use case group.

	Distinction between requirements and constraints is probably
somewhat arbitrary at this point. For some people the constraints will be at
least as important as the functionality of the finished spec. i.e. if what
is built does not work with XML Signature some of us will be going home
regardless of what the beast will do...

	Feel free to add, suggest moving terms arround etc.


Requirements
------------

[R-AuthAttr]	Communicate Authorization attributes
	e.g. 'Alice has tier 1 credit'
	e.g. 'Alice is a finance administrator in X corp'

[R-AuthDecision]	Communicate Authorization decision data
	e.g. 'Alice is allowed to access file xxx-yyy.txt'

[R-Integrity]	Communications to be Authenticated
	
[R-MultiDomain]	Support for communication across multiple domains
	e.g. companies A, B, C use S, a hosting service for myERP. Each
company connects to the same harware but has access to different partitions.
Many different people work for A and S does not want to track which person
at A has access to which specific resource at S.
	In addition company S also outsources its payroll to T and is a
member of biz exchanges U, V. There is clearly a need for A to be able to
manage all authorization data through a single system that communicates to
S, T, U, V etc.

[R-SingleDomain]	Support for communication of authorization data
within a single domain
	The case that a company is simply controlling access to its Intranet
resources (Web server, mail, document store etc.) must also be supported
cleanly.

[R-Authentication] Authorization data must bind securely to Authentication
data
	Here there is room for a lot of different architectural
implementations that I don't want to call requirements.

[R-Session]		Authorization data to be scoped by a 'session'.
	At the very least some means is required to allow a client to
control the use of credentials beyond the current request. 

	
Constraints
-----------

[C-XML]	Protocol to be encoded in XML
	Pretty much the staring point.	

[C-Sig]	Protocol to be consistent with XML Signature
	Follows from [C-XML] IMHO. Any arguments?

[C-XKMS]	Protocol to be consistent with XKMS processing of XML
Signature KeyInfo elements
	Should follow from [C-Sig]

[C-XTASS]	Protocol to be consistent with XTASS framework
	This is a slightly bogus 'constraint' since the intention is that we
change XTASS to track changes in S2ML. Its like drawing the target arround
where the arrow fell. But the arrow does have to fall somewhere that makes
it possible to draw the target arround. Really this one comes down to
extensibility. 

[C-Open]	Be 'open' and 'extensible'
	

[C-Mess]	Minimize the number of messages required to support
interesting use cases.
	
[C-PassUse]	Should support users that only have password means of
authentication

[C-PassCli] ?? Should support clients with no public key crypto ??
	This does not follow from [PassUse]. A client could generate a
public/private keypair and then use a password to authenticate itself to the
authorization server which would bind to the just generated public key. This
may not be generally acceptable in clients but the assumption of PK does
simplify interdomain authentication issues considerably.


Architecture
------------

Bit soon yet but some observations:

1) URIs are the Turing machine equivalent for the Web. This is handy when
faced with [R-MultiDomain] and [R-SingleDomain]

	This is also handy since it allows artificial distinctions between
resource names, roles, etc. to be avoided. In S2ML and Auth-XML I see a lot
of 'nested' transactions that obtain different shades of authorization that
to me can all be represented with a URI.

2) Binding of authentication data, there are some very different approaches:

* Authentication establishes an authentic binding of an authentication token
(i.e. a shared secret or a public key) to a UserName, Authorizations are
securely bonud to the name.

* The authorizations are securely bound to the authentication token itself,
avoiding the need for to establish a name.

3) There is also a need to support a particular corner case for HTTP cookie
implementations. Here the authentication token and possibly the auth data
needs to be inserted in either a cookie or a URL or something.

Here I see two possible approaches

* Try to encode all the data into the cookie or the URL, this has the
advantage of simplicity but has the disadvantage of sending an awful lot of
data arround. URL encoding schemes in particular could significantly bulk
out a page of HTML.

	[Why didn't I suggest a Meta tag to allow extra data to be carried
out with links instead of Referer?]

* Most of the data is repetative and could be compressed or sent by
reference. It is not really necessary to encode the authorization or
authentication data itself, merely a secure binding thereto.

4) Message flows, services

There are several potential message flows:

Flow

1) Client C attempts to access resource B, is told to obtain auth credential
from server A
2) C obtains credential from A
3) C repeats request, presents credential to B
4) C makes additional request, presents credential to B
[5) C informs B that credentials are no longer to be accepted (logout)] 

This brings up a couple of questions

* In (4) how does C know if the credential recieved is still in scope?

* Logout (5) is a feature of password authentication processes. If the token
itself is presented only way to stop reuse of the token is to tell the
server not to accept it again. this is hyper unsatisfactory since it means
that the resource server has to maintain state so that it knows which tokens
are live and which are not. A better and more secure all round solution is
to use something like digest authentication, the session can then be ended
by deleting the token in the client [note that this may require some means
for the resource to tell the client to delete the token].

HTTP is idempotent which is why these is no session notion in HTTP and why
we need S2ML. What I should have done in digest is to provide a means of
presenting a password en-clair the first time but bound to a second token to
be used in future requests.

4a) Server side redirect

Another way to solve the problem is to have the server do all the
communication with the auth server:

1) Client C attempts to access resource B, is told to obtain auth credential
from server A
2) C request credential from B
	request is forwarded to A
	credential returned to C
3) C repeats request (redirect), presents credential to B
4) C makes additional request, presents credential to B
[5) C informs B that credentials are no longer to be accepted (logout)] 


5) HTTP binding

We can always clean up the HTTP binding by defining our own authentication
scheme. 

		Phill

Philip Hallam-Baker.vcf

---