Re: Identity Checking in Application Protocols

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

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

On 10/28/09 11: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,

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/


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

iEYEARECAAYFAkroreYACgkQNL8k5A2w/vzLxQCgyq8pMpcdQwQeMgTCuYCX1UJ8
YgYAoPza3tbBwEibE/NR+O6Rv6wX2j03
=eH/U
-----END PGP SIGNATURE-----