Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication

From: Tobias Gondrom <[email-masked]>
Date: Wed, 28 Jan 2004 14:54:02 +0100

> As suggested, I just take a subpart of the messages and add 
> some centimes in a brain storming way.
> 
> > User authentication is another problem in wide scale deployment of 
> > archive services. Bearing in mind that privacy is one of the (more and 
> > more) important factor in open infrastructure,  confidentiality is even 
> > more important in case of formal content handling (contracts, 
> > invoices!!).
> 
> > Furthermore, DVCS exposes the content to authority at least, and has 
> > serious confidentiality problems...
> 
> If you think about a chain of a notary that validates formal 
> content and then needs to store the data at some external 
> service, there is no formal way to ensure either encryption 
> or splitting so that the assertions from the backend service 
> can be matched with the statement from the
> notary. Needs some work ...   
> 
> > I see the authentication problem quite similar and have at the moment 
> > not the optimal solution for it. :(
> 
>  User authentication doesn't seem for me a particular problem 
> for  the archive service, it may or may not be a problem for 
> any  large scale service. 
> 
>  That's why I think we should not try and mandate a 
> particular way  but allow for different techniques, including:
> 
>  - Access control on the transport level (e.g. SSL).
>  - Signatures in order to keep some proof.
>  - asynchronous staged processing for certain operations
>    where requests need to be confirmed by someone else.
> 
>  The meaning of 'Optimal' depends on the goals. 

I agree with you Peter. Seems to be better to allow authentication but we
don't need to specify the used technique so that different services are free
to implement what fits best.

> > On the one side you have to be able to store data and with this the 
> > retrieval has to authenticated and access control has somehow to be 
> > applied.
> > 
> > On the other hand how can one achieve authentication across very long 
> > times spans of decades ?
> 
> Isn't Authentication 'at distance' but not 'in time'. 

Basically I see a problem concerning the time too. The methods of
authentification may change during the lifetime of a document (even more
than once). And with that you might get problems.
Let's e.g. say you archived a contract about your newly bought house or
something and used at the beginning user/password authentication. For the
next 20 years you are basically probably not interested in the document and
might even forget your password, although you still have the URL of the
document with all the evidence records. In the future maybe even
user/password authentication is no longer accepted by the server so you need
something different 
- but what is important for the system: are you the same person that stored
the document 20 years ago ?

> But we talk about authorisation? It may be necessary to handle in 
> some way particular roles 
> like 'a judge/relevant authority' and then the access control 
> may require some 'entitlement'. This entity from the fiscal 
> service is entitled to access to data from company identified 
> by XXX'. how these meachnisms are implement now or in future 
> is not in our scope, I think what remains is that the 
> exchanged and stored information contain sufficient 
> 'metadata' indicating to whom the belong using good identifiers. 
> Either a client should explicitely set some identifiers in 
> requests, which need then matched against the authenticated 
> client id, or they are added by the server based on the 
> client id or maybe additional parameters in the request.  

Authorisation: 
In my understanding authorisation comes after some kind of authentication
(i.e. at first you know the identity of the other and then you think about
to allow him access to the data).

A role based access control seems feasable and hopefully not to complicated.
(Maybe added with some sercret (document id ?) generated at the time of
storage.) 

The "judge/relevant authority" is of course on. 
A second one will be the user who stored the data. (Of course he wants to be
able to receive the evidence and maybe even the data he stored.)

Small remark: If the trusted archive does not provide the data itself to
normal requests, the authorisation topic might be easy, as I think the
retrieval of evidence to a document might not be a security issue. The
request for evidence could contain either the data or a hash-value of the
data (as long as the hash-algorithm is still secure).

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 29 Jan 2004 13:08:34 +0100 (MET)

> 
> I agree with peter completely. I also think one needs to clarify what
> procedures are we discussing about. Authorization is something that
> gives you power (or not) to access or use something. While
> identification is something else. So in case of archival services
> authorization is seen through rights to use the service or not (and of
> course the level of usage). However we still must keep the fact in mind
> that whatever we are archiving always belongs to somebody (something??).

Yes, and it seems that the question is to what degree the payload data
are ... let's labelled or tainted with identification, types, roles,
locations, etc. 

Such information need to be grouped in several categories depending
on at least three interested parties:

- the client itself, delegation of rights to employees or roles
- the service (to distinguish groups of users, accounting, etc
- other relying parties and external authorities
  (fiscal identification, locality, jurisdiction, ...)
 
> So the major question is: who has the rights to access the archived
> item? And after that: how do we identify the person with the acess
> rights? I think this should be clarified before we can even discuss the
> operational steages of the service.

There are many things which seems out of scope of this group. I
am not sure whether one has to develop more than containers and
type indications for identification data can be provided by/for a requester
and for information can be associated to the request and response payloads
so that these can be input for some decision making service using
things like XACML SAML ... 
 
> My wiev is, that this two main functions might be separated (although
> tightly corelated to the service), i.e. an authority identifying
> subjects in an open environment or mapping the rights to a subject. For
> example, as Peter stated, if I put something in the archive on behalf of
> my company, who will access the same archive once I change my job? Where
> are the connections between former and present employee? 

Just to remind another point: The authorition decision may not be possible
'on line' (as in many real life cases), thus a request to retrieve
or validate cannot necessarily be answered immediately and may need
manual intervention.
Such a delay is not a problem, since it may be necessary to retrieve
some disk from a bunker or else.  

Peter