[secdir] secdir review of draft-lawrence-sipforum-user-agent-config-01

[Jeffrey Hutzelman <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes a process by which a SIP User Agent can obtain
configuration from a Configuration Service (CS) with a minimum of user
interaction.  This is particularly important since SIP UA's may be
included in devices such as telephone adapters which are installed by
end users and have little or no provision for user interface.

The process described is relatively straightforward:
- use LDDP-MED to get layer 2 up
- use DHCP to get layer 3 up, and discover a local domain name
- use U-NAPTR to turn the "configuration service name" (either the local
  domain name or a manually-entered name) into a set of one or more
  base configuration URL's
- add some query parameters identifying the client, and use HTTPS GET


Section 2.4.1 discusses authentication.  The client is required to use
the TLS server_name extension; however, the server name it is required
to request is the name taken from the host part of the URL(s) obtained
from U-NAPTR, rather than the Configuration Service Name (i.e. the local
domain name or a manually-configured name).  The latter should be used,
so that the DNS-based indirection facilities are not required to be secure
for the system to work.

While DHCP is almost universally not secured, eliminating the need for
pre-secured DNS still provides a substantial improvement.  First, it is
relatively easy for a deployment to require a user to enter a configuration
service name rather than relying on one obtained from DNS.  In fact, it
may even be necessary to do so; for example, a telephone service provider
offering SIP phone service to users via their existing home network cannot
rely on being able to provide a particular domain name in the DHCP responses
provided by an ISP or by the user's consumer-grade router/NAT box.  Second,
the resolution of the CS name to a base URL may require DNS queries to the
internet at large, outside the user's network.  Again, consider the case of
a telephone service provider offering service via the user's existing 
network.

This section says the UA SHOULD validate server certificates if possible, 
and
otherwise MAY use SSH-style leap-of-faith.  This seems reasonable for this
application, where the use is provisioning a new device which, by 
definition,
usually cannot have previously-provisioned trust anchors.

Clients are REQUIRED to send a certificate if they have one, but are not
required to have one.  A CS SHOULD validate the client's certificate, and
otherwise MAY do leap-of-faith caching, provided that HTTP authentication
succeeds on this connection.  However, it is unclear what, if anything, the
client certificate identity is used for.  If this identity is not used, then
use of client certificates is pointless.  Further, since HTTP authentication
is not cryptographically bound to the TLS layer, successful HTTP auth does
not demonstrate anything about the validity of the client certificate.