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

[Sandra Murphy <[e-mail]>]

On Thu, 16 Jul 2009, Polk, William T. 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?

rfc4930bis mentions a couple of others in sect 2.1 Transport Mapping 
Considerations

    -  The transport mapping MUST be onto a transport such as TCP
       [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960]
       that provides congestion avoidance that follows RFC 2914
       [RFC2914], or if it maps onto a protocol such as SMTP [RFC5321] or
       Blocks Extensible Exchange Protocol (BEEP) [RFC3080], then the
       performance issues need to take into account issues of overload,
       server availability, and so forth.

I don't know how close to "in the works" those other suggested examples 
are.

Later it says that EPP can be carried over both connection-less and 
connection oriented transports.

And the security considerations section says that

                          EPP instances MUST be protected using
    a transport mechanism or application protocol that provides
    integrity, confidentiality, and mutual strong client-server
    authentication.

--Sandy

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