Re: [secdir] review of draft-hollenbeck-rfc4933bis-02

["Polk, William T." <[e-mail]>]

Alexey,

I just went back and looked at 4934bis... You were right, there is no
channel bindings problem there.

I missed the fact that client certs are *required*, since the bulk of the
section specified how the client should verify the server identity, but no
such text exists for the client cert.  Probably should correct that
oversight, but there is no systemic problem.

Still mulling over 4930...

Any reason we can't make 4934bis the mandatory to implement transport?

Tim 



On 7/16/09 10:54 AM, "Polk, Tim" <[e-mail]> wrote:

> Hi Alexey,
> 
> 
> On 7/16/09 7:18 AM, "Alexey Melnikov" <[e-mail]> wrote:
> 
>> Hi Tim,
>> 
>> Polk, William T. wrote:
>> 
>>> I¹m a little late to the party, but I have been quietly mulling over
>>> this problem as well. Now that Sandy has explicitly asked for an AD to
>>> step in, I figured I should participate more actively. I have also
>>> added Nico Williams to the CC list (my apologies, Nico) since channel
>>> bindings is really his area of expertise.
>>> 
>>> I think there is a real need for channel bindings with some
>>> applications of EPP, but may not always be strictly necessary in other
>>> cases. For example, the e-Automation project for the administration of
>>> DNS root zone uses EPP but if I recall correctly most of the objects
>>> that are transferred are digitally signed objects. In this case,
>>> channel bindings are perhaps less important since we aren¹t relying
>>> solely on the EPP authentication mechanism. So, in my opinion we
>>> should encourage their use but should not require channel bindings.
>> 
>>> 
>>> However, if the application is relying on EPP in combination with
>>> transport for security, channel bindings would provide significantly
>>> enhanced security. That says channel bindings deserves to be mentioned
>>> and a little guidance on (1) implementing channel bindings and (2)
>>> determining when channel bindings is required. That begs a new
>>> question of course ­ where does this information go?
>> 
>> Nico's response confirmed what I was thinking about this myself: for EPP
>> running over TLS over TCP (4934bis), channel bindings are not required,
>> because TLS authentication is mandatory and because TLS server
>> certificate verification procedure is also mandatory.
>> So I don't think there is an issue with 4934bis document.
>> 
> 
> I'm not so sure... TLS server certificate verification protects the client
> against a MITM attack.  The server has no way of knowing whether this
> procedure has been implemented.  So, the server does not have all the
> protection it needs unless the TLS connection uses client certificate
> authentication as well.
> 
> Channel bindings would extend the level of assurance for the server.
> Alternatively, mutual authentication using certificates would resolve the
> problem as well.
> 
>>> I am starting to believe that the security considerations section of
>>> 4930bis should note that enhanced security SHOULD be achieved through
>>> channel bindings unless the application involves digitally signed objects,
>> 
>> I think another alternative can be to require mutual TLS authentication
>> in a transport protocol mapping document.
> 
> I think that would be a great solution, and it wouldn't need to tamper with
> EPP or 4934bis.  Any new EPP transport protocol mappings in the works?
> 
>> 
>>> and that the TLS usage section of 4934bis (section 9) should include a
>>> pointer to techniques for implementing channel bindings with TLS.
>> 
>> As per my coment above, I don't think this is needed.
>> Besides adding channel bindings to EPP would require an extension to EPP
>> itself.
> 
> That has been part of my concern from the beginning.  Since we are progressing
> to Full Standard, extending EPP is pretty much a non-starter.
> 
> That is why I would prefer to restrict my discuss or comment to raising
> issues in the security considerations of 4930bis.
> 
>> 
>>> I am still mulling this over, and will probably not enter any discuss
>>> until tomorrow, but this seems the best approach. (Hopefully Nico will
>>> weigh in before then and keep me straight on this one...)
>> 
>> 
>>