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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Sandra Murphy [mailto:[e-mail]] 
> Sent: Thursday, July 16, 2009 12:01 PM
> To: Polk, William T.
> Cc: Alexey Melnikov; Hollenbeck, Scott; Catherine Meadows; 
> [e-mail]; Nicolas Williams; [e-mail]
> Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-02
> 
> 
> 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.

I'm not aware of any other IETF work to develop a standards-track transport mapping for EPP.  I have heard that other transports are being used by ccTLDs (they often "roll their own" when it comes to how they operate), but I don't have specific info on-hand.

-Scott-