Subject: Identity Checking in Application Protocols

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Oct 2009 17:03:19 -0600

I had hoped to update draft-saintandre-tls-server-id-check before the
submission cutoff today, but it's not going to happen because there's
quite a bit of feedback to sift through (ideally I would have followed
the list discussions more closely the first time around).  However, I
shall work to update it in the next few days, at which time I will also
rename it to remove the strings "tls" and "server" since the scope of
the spec has widened to include non-TLS interactions as well as client
identity checking. My apologies for the delay.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Oct 2009 10:28:30 +0000

Hi Peter,

> identity checking. My apologies for the delay.
Without my AD hat: I don't think the document should cover client 
identity checking. I found Kurt's arguments to be convincing.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Oct 2009 15:28:40 -0600

> identity checking. I found Kurt's arguments to be convincing.

I think that the distinction between application roles and security
roles causes some confusion here. This I-D talks about security roles,
not application roles. Thus, for example, when two XMPP servers wish to
establish a TLS-encrypted connection, from the security point of view
the server that initiates the connection is a TLS client whereas the
server that receives the connection is a TLS server (despite the fact
that from an application point of view both of them are XMPP servers).

My understanding of Kurt's argument is that we can't say much that's
helpful about how a TLS server checks the identity of a TLS client
because the problem is application-specific and the TLS server doesn't
really have a "reference identity" (an idea of what identity the client
will assert). At some level, the TLS server knows that it expects the
TLS client to assert a kind of identity (domain name, email address,
XMPP address, etc.) but not necessarily a particular instance of that
kind ("example.com", "[email-masked]", or whatever).

I need to think about this further. I'm sure that re-reading Kurt's
messages will help...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Oct 2009 16:18:35 -0600

On 10/27/09 4:17 AM, Miika Komu wrote:
> Peter Saint-Andre wrote:
> 
> Hi Peter,
> 
> could you add a section on RFC4843 based authentication? Some other
> references:
> 
> http://tools.ietf.org/html/rfc5338
> http://tools.ietf.org/html/draft-ietf-hip-native-api

Thanks for the references, I will check those out.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Miika Komu <[email-masked]>
Date: Tue, 27 Oct 2009 12:17:43 +0200

Peter Saint-Andre wrote:

Hi Peter,

Thanks!

P.S. I also find somebody who can also contribute text if this is needed.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrmKrcACgkQNL8k5A2w/vzfTwCfaOtoWUS6yE8r1kaAoo70Ae3f
> Ng4AnjBF+Y/k7EKxE47IhXwIcBIPdu7h
> =uuU1
> -----END PGP SIGNATURE-----
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "tom.petch" <[email-masked]>
Date: Wed, 28 Oct 2009 18:20:41 +0100

----- Original Message ----- 
From: "Peter Saint-Andre" <[email-masked]>
Sent: Tuesday, October 27, 2009 10:28 PM
 
> I need to think about this further. I'm sure that re-reading Kurt's

My take is that the only difference is one of number.

A client is 'configured' with a single reference identity, eg by the user
keying it into a window, which is then used in a comparison with what 
is returned in an X.509 certificate.

A server may support more than one client and so may be configured
with more than one reference identity and use any or all of them in a 
comparison with what is received in an X.509 certificate eg with SIP, 
Netconf, syslog,
....

Of course, a server may not care to check, may not be configured with 
anything, in which case the procedures in this I-D are irrelevant

Tom Petch

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2009 14:47:34 -0600

> comparison with what is received in an X.509 certificate eg with SIP, 

That's an interesting perspective.

In my experience (which is mainly limited to XMPP networks), the largest
deployment of certificate-based authentication does not expect that the
server will find an XMPP address in the client certificate. Instead, it
finds some other information in the cert and uses that information to
dynamically construct an XMPP address for the client on the server.
However, I freely admit that this usage is non-standard and not
something we'd want to document.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 28 Oct 2009 15:53:35 -0500

> That's an interesting perspective.

An approach that we took in SIP for the server to authenticate
clients is documented in Section 7.4 of ietf-sip-domain-certs
(http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04#section-7.4).

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 29 Oct 2009 07:51:00 -0700

> anything, in which case the procedures in this I-D are irrelevant

My objection is not against an "application server" acting as a TLS  
client verifying the identity of the TLS server it connects to.
My objection is against this I-D discussing in detail how an  
"application server" acting as a TLS server might verify the identity  
of the TLS client connecting to it.

The difference between the two (generally speaking) is that in the  
former, the verifying entity (the TLS client) has an assumption of  
trust in the reference identity as it provided by the user (via some  
dialog or configuration or whatever) as opposed to be programmatically  
determined by the verifying entity (such as simply using the TLS  
client's IP address as the reference identity, or using some IP  
address to reference identity mapping, etc.).   The security  
considerations for these two scenarios is quite different, and I  
simply rather avoid discussing the latter in this document.

I note that are other use scenarios, such as when the reference  
identity is provided to the client via a referral mechanism.  That is,  
an application clients to server A, A provides a referral to B, client  
connects to B and now wants to verify B's identity.   I think this  
scenario likely should be discussed to some degree in the I-D as it is  
a relatively common application client scenario.

-- Kurt

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Oct 2009 09:39:58 -0600

On 10/29/09 8:51 AM, Kurt Zeilenga wrote:
> "application server" acting as a TLS server might verify the identity of
> the TLS client connecting to it.
> 
> former, the verifying entity (the TLS client) has an assumption of trust
> in the reference identity as it provided by the user (via some dialog or
> configuration or whatever) as opposed to be programmatically determined
> by the verifying entity (such as simply using the TLS client's IP
> address as the reference identity, or using some IP address to reference
> identity mapping, etc.).   The security considerations for these two
> scenarios is quite different, and I simply rather avoid discussing the
> latter in this document.

Agreed, I would rather keep this I-D focused on the application client's
task of verifying the identity of an application server. But nothing is
stopping us from writing another I-D that focuses on other problems.

> I note that are other use scenarios, such as when the reference identity
> is provided to the client via a referral mechanism.  That is, an
> application clients to server A, A provides a referral to B, client
> scenario likely should be discussed to some degree in the I-D as it is a
> relatively common application client scenario.

Yes, I think it would be good to discuss that scenario, although I
confess that I don't have a clear handle on what text would be appropriate.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 29 Oct 2009 09:22:50 -0700

On Oct 29, 2009, at 8:39 AM, Peter Saint-Andre wrote:

>>>>>> shall work to update it in the next few days, at which time I  
>>>>>> will
>>>>>> also
>> trust
>> identity

I think our description of the 'reference identity' is a bit too vague.

    reference identity:  The client's conception of the server's  
identity
       before it attempts to establish a secure connection to the  
server,
       i.e. the identity that the client expects the server to present
       and to which the client makes reference when attempting to verify
       the server's identity.  It is either the address to which the
       client connected or the explicit value of the TLS "server_name"
       extension as specified in [TLS].  The reference identity might be
       based on a DNS lookup, user configuration, or some other
       mechanism.

One could easily read "server's identity before it attempts to  
establish a secure connection to the server" as any identity the  
client has for the server before it does the connect(2) call (or  
equivalent).  That is, one can view DNS name to IP address mapping as  
occurring before attempting to connect to the server.

The reference identity is either the identity of the server that the  
user provided to the client, or its an identity of the server somehow  
other obtained (such as via a referral) from another entity (such as 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.

The document needs to discuss this distinction.   My recommendation is  
to leave the particulars of the latter case to application protocol  
specifications that make use of the algorithm (as it's the same basic  
issue with client identity checking, is the reference identity  
trustworthy or not).

I don't have text to offer at this point...

-- Kurt

> iEYEARECAAYFAkrpt04ACgkQNL8k5A2w/vxRnQCffTdMhPDMKDszdzwQQe4+S0lY
> 9bUAoO4US35ITGOEPPdo582FqV+jZHIp
> =TWvB

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Oct 2009 15:43:20 -0600

>> I think our description of the 'reference identity' is a bit too vague.

I agree.

>>    reference identity:  The client's conception of the server's identity
>>       before it attempts to establish a secure connection to the server,
>> One could easily read "server's identity before it attempts to establish
>> a secure connection to the server" as any identity the client has for
>> the server before it does the connect(2) call (or equivalent).  That is,
>> one can view DNS name to IP address mapping as occurring before
>> attempting to connect to the server.

IMHO that's not what we meant, so we need to make it clearer.

>> other obtained (such as via a referral) from another entity (such as a

Do you have examples of referral services and the concept of referral in
general?

>> 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".

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 29 Oct 2009 19:13:31 -0700

> Do you have examples of referral services and the concept of  

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.

>>> trusted.

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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 30 Oct 2009 11:19:59 +0100

---- Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: "Kurt Zeilenga" <[email-masked]>
Cc: "tom.petch" <[email-masked]>; "Alexey Melnikov"
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 29, 2009 4:39 PM
Subject: Re: Identity Checking in Application Protocols

Peter

I don't think we can say anything about <application> client or server.

We are dealing with TLS or a similar protocol presenting an X.509
certificate for authentication, and the client for the security protocol
may be the server for the application or not as the case may be
so while I do not want us to restrict ourselves to TLS, I also think it
wrong to refer to application.

If you do need to differentiate the two ends of the connection (I dont':-)
then I suggest transport client and transport server, although even that
is not quite right as the TCP client could be the TLS server, ie they are
eight choices in prospect.

Tom Petch