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

[Nicolas Williams <[e-mail]>]

On Thu, Jul 16, 2009 at 12:01:09PM -0400, Sandra Murphy wrote:
> 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.

Incidentally, that text is not clear.  How do "performance issues" take
anything into account?  Someone should be taking "issues of overload"
(uncomfortable wording, that), and so on, but who?  The implementor?
Designers of new transport mappings?  Who?

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

Which means TLS, DTLS (for connection-less transports), and maybe SASL
(for BEEP?  SMTP should use TLS).

Note that "mutual strong client-server authentication" needs definition.
In particular the adjective "mutual" as applied to "authentication" can
mean one of two things:

a) Each party's identities are authenticated to the other

OR

b) Authentication does not complete until the party being authenticated
   sends a message that proves it.

   For example, say you're using RSA key transport to encrypt a session
   key in the server's public key.  The server's ability to decrypt the
   session key authenticates the server, but the client won't know that
   the server successfully decrypted the session key until the server
   sends back a message proving it knows the session key.  TLS includes
   such a message.

   This meaning of "mutual authentication" comes from Kerberos, where
   it means that the server will send an AP-REP reply to a client's
   AP-REQ message.

Here I suspect that EPP wants (b), since it will send a username and
password over the secure channel to authenticate the user.  If TLS were
authenticating the user in the first place (as in (a)), then there would
be no need for username and password authentication.

The "strong" adjective also needs some explanation.  I suspect that
what's really desired here is that the _server_ be authenticated via
certificates, while the client will be authenticated by sending a
username and password over the secure channel.  As opposed to both, the
client and server being authenticated to the other via certificates.

Perhaps this would be clearer text:

                         EPP instances MUST be protected using
   a secure, end-to-end channel, at a suitable layer, that provides
   integrity and confidentiality protection, and strong server
   authentication.  Authentication of the server to the client MUST be
   "mutual" in the Kerberos V5 [RFC4120] sense: the secure channel must
   require that the server send a message establishing that key exchange
   and authentication are complete and that the server has access to its
   authentication credentials and knows the session key.

Nico
--