Re: Identity Checking in Application Protocols

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

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

On 10/29/09 10:22 AM, Kurt Zeilenga wrote:
> 
> On Oct 29, 2009, at 8:39 AM, Peter Saint-Andre wrote:
> 
> 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.
> 
> 
>> 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,
>>       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.

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

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

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/


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

iEYEARECAAYFAkrqDHgACgkQNL8k5A2w/vz8zACg3mp0V5Yiwau20EdOrUP+qAqr
vHUAnRTLlaWglwflbzvHlg82Z6e1KUzv
=PJbF
-----END PGP SIGNATURE-----