Re: Identity Checking in Application Protocols

[Kurt Zeilenga <Kurt.Zeilenga at Isode.com>]

On Oct 29, 2009, at 2:43 PM, Peter Saint-Andre wrote:
> Do you have examples of referral services and the concept of  
> referral in
> general?

In directory services accessible by LDAP, an LDAP server can refer the  
LDAP client to another LDAP server.
In web services accessible by HTTP, an HTTP server can redirect the  
HTTP client to another HTTP server.
A URN resolver service is effectively a referral service.

> > > In the former case, the reference identity is to be implicitly  
> > > trusted.
> > > In the latter case, there should be no implicit trust.
>
> I'd be curious to hear your description of "implicit trust".

To me, as used in this thread at least, "implicit trust" implies the  
information authenticity is unquestioned.

As a client is acting upon the behalf of a user, information provided  
by the user is implicitly trusted.  That is, if a user tells a client  
to return the resource located by some identifier, that identifier is  
not to be questioned.  However, in accessing the resource that  
identifier identifies, some resolver, redirection, referral, or like  
service is involved, the authenticity of the service's output should  
be questioned.

Let me give you an example.

A user asks their RFC3088-supporting LDAP client to access the object  
identified by the DN <dc=example,dc=org>.  The client maps this DN to  
the domain example.org (using the RFC3088 algorithm) and finds DNS SRV  
records for this domain refer to server example.net.  The client then  
looks up the IP address for example.net, and connects to the  
appropriate service at that IP address to access the named object.

I consider the reference identity in this case is <dc=example,dc=org>  
and hence it is implicitly trusted.  The domain name example.org is  
directly derived from this reference identity via the RFC3088  
algorithm and, hence, can also be implicitly trusted.  But the RFC3088  
resolver output, example.net, and the domain name to IP address  
resolver output, the IP address, should not be implicitly trusted and  
should be used in verification that the server is the server the user  
asked (via the DN) to connect to.

It would be reasonable for an LDAP client to verify the server  
certificate via <dc=example,dc=org> and DN-valued subject information  
(the particulars of which are reasonably beyond the scope of this I-D)  
and/or verify the server certificate using example.org and domain- 
valued subject information.

-- Kurt