[MMUSIC] comedia-tls: proposed change for certificate identities

Hi, all --

I'm working on a revision of draft-ietf-mmusic-comedia-tls following IESG
review.  A preliminary version of the revised draft is available at
<http://www1.cs.columbia.edu/~lennox/draft-ietf-mmusic-comedia-tls-06pre1.html> and
<http://www1.cs.columbia.edu/~lennox/draft-ietf-mmusic-comedia-tls-06pre1.txt>;
a document showing changes from the previous version is at
<http://www1.cs.columbia.edu/~lennox/draft-ietf-mmusic-comedia-tls-06pre1.diff.html>.

Most of the issues raised resulted in pretty minor and hopefully
uncontroversial changes, but one change, having to do with certificate
identity choice, is fairly major.  I'm still
uncertain about the practical usability of the resulting rules.

Here's the scheme I'm proposing:

* If your SDP was sent over an end-to-end authenticated and
integrity-protected channel, there are no constraints on what identity you
assert in your TLS certificates; you can use anything you want.  Identity is
handled by the transporting protocol.

* If it wasn't, however, you have to have use certificate that asserts
either a) the host in your SDP c= line (which can be either an IP address or
host name), or b) a URI representing the protocol transporting the SDP
(which in practice usually means a SIP URI).

* For self-signed certificates sent un-authenticated, you can use SSH
"leap-of-faith" mode: you warn the user if you've never seen a certificate
before for a given identity, or if the certificate you got for an identity
is different from the one you have cached.  This means that once you've
communicated with someone, you can be sure no one's launching a
man-in-the-middle on you in the future.  It does, however, present usability
problems when someone has to change their cert.

* For SIP, if the unauthenticated cert you get (whether or not self-signed)
doesn't reflect the AoR of the party you initially contacted, the user is
again warned and user confirmation is requested.  (This applies whether it's
a different AoR, a device URI, or a hostname/IP address.)

This last point is the tricky one.  The goal here is that if you were trying
to reach sip:alice@example.com, and you get a cert asserting the identity
sip:bob@example.com, this could be a problem, and only a human can usefully
determine whether it is or not.

Of course, given that the initial user of comedia-TLS will be BFCP, for
which at least one side is an automated system without a human in the loop,
it's not entirely clear how practical this requirement will be.  But the
alternative leaves you vulnerable to hostile or subverted sip proxy servers.

The other question is whether it's worthwhile to say that single-hop sips
connections should count as end-to-end integrity-protected.  On the one
hand, they are; on the other hand, allowing certain operational modes for
single-hop but not multi-hop SIP seems like a bad idea, and it would break
in the face of third-party call control and other back-to-back UAs.

Do people have alternate suggestions, or thoughts on better solutions?  I
note that these requirements are strictly more lenient than the protocol
mode which got through WGLC.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic