Re: Identity Checking in Application Protocols

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/29/09 8:51 AM, Kurt Zeilenga wrote:
> 
> On Oct 28, 2009, at 10:20 AM, tom.petch wrote:
> 
>> ----- Original Message -----
>> From: "Peter Saint-Andre" <stpeter at stpeter.im>
>> Sent: Tuesday, October 27, 2009 10:28 PM
>>
>>> On 10/27/09 4:28 AM, Alexey Melnikov wrote:
>>>> Hi Peter,
>>>>
>>>> Peter Saint-Andre wrote:
>>>>> 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.
>>>>>
>>>> Without my AD hat: I don't think the document should cover client
>>>> 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", "foo at example.com", or whatever).
>>>
>>> I need to think about this further. I'm sure that re-reading Kurt's
>>> messages will help...
>>
>> 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
> 
> 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.

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

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/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrpt04ACgkQNL8k5A2w/vxRnQCffTdMhPDMKDszdzwQQe4+S0lY
9bUAoO4US35ITGOEPPdo582FqV+jZHIp
=TWvB
-----END PGP SIGNATURE-----