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

From: Jonathan Lennox <[email-masked]>
Date: Sun, 29 Jan 2006 14:04:02 -0500

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:[email-masked], and you get a cert asserting the identity
sip:[email-masked], 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
[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Jan 2006 15:19:37 -0500

>>>>> "Jonathan" == Jonathan Lennox <[email-masked]> writes:

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

What about hop-by-hop authenticated with each hop integrity protected.
IMHO in many environments, this presents acceptable man-in-the-middle
risk.  I think that it may present significantly easier to deal with
usability issues so I think it should at least be allowed if not
encouraged.

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

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

Do you have explicit language that a self-signed cert cache must not
get in the way of the rekeying in the previous two cases?
    Jonathan> The other question is whether it's worthwhile to say
    Jonathan> that single-hop sips connections should count as
    Jonathan> end-to-end integrity-protected.  On the one hand, they
    Jonathan> are; on the other hand, allowing certain operational
    Jonathan> modes for single-hop but not multi-hop SIP seems like a
    Jonathan> bad idea, and it would break in the face of third-party
    Jonathan> call control and other back-to-back UAs.

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 30 Jan 2006 08:22:12 -0500

> usability issues so I think it should at least be allowed if not

This will certainly be the most common way of securing SDP, I think -- this
describes how sips, i.e. sip over hop-by-hop TLS, works.  You're vulnerable
to a broken or subverted sip proxy server, but otherwise you're safe.

If there's consensus that it's acceptable to allow this mode, I can add
language allowing it.  However, I think this is a big enough change I'd like
to hear positive consensus for it; this should get something more than just
consent-by-silence from the working group.

> get in the way of the rekeying in the previous two cases?

I'm not sure how I distinguish rekeying from a man-in-the-middle attacker
presenting a new certificate.  Is there an obvious distinction here?  Does
it have to do with certificate expiration?

-- 
Jonathan Lennox
[email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Jan 2006 15:50:36 -0500

>>  Do you have explicit language that a self-signed cert cache
    >> must not get in the way of the rekeying in the previous two
    >> cases?

    Jonathan> I'm not sure how I distinguish rekeying from a
    Jonathan> man-in-the-middle attacker presenting a new certificate.
    Jonathan> Is there an obvious distinction here?  Does it have to
    Jonathan> do with certificate expiration?

Basically,  what I never want to happen is:

* you get a self signed cert in a previous session

* In the current session you have end-to-end integrity and get
  errors/warnings because you are not getting the same cert you did in
  that previous session.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 30 Jan 2006 16:38:59 -0500

>   errors/warnings because you are not getting the same cert you did in

Oh, I see.  Yes, if you receive a cert with end-to-end integrity, it should
never warn you about certificate mismatches; I'll make sure that language is
clear.