Subject: [Sip] draft-ietf-sip-media-security-requirements-05

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 May 2008 15:48:30 -0700

I just checked in draft-ietf-sip-media-security-requirements-05 with the
following changes:

  * moved 'shared keyed conferencing' section to Appendix B.

  * added motivation text for R-OTHER-SIGNALING (new Section 4.8) 
    and R-CERTS (new Section 4.9)

  * R-CERTS now reads:

      The media security key management protocol MUST NOT constrain	
      the set of trust anchors that a peer can use to validate	
      certificates used in the protocol.

  * other minor changes

side-by-side differences are available at http://tinyurl.com/6hy85b

http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements
-05.txt

-d

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 05 May 2008 17:01:10 -0700

At Mon, 5 May 2008 15:48:30 -0700,
Dan Wing wrote:
At Mon, 5 May 2008 15:48:30 -0700,
>       certificates used in the protocol.

I don't mean to be difficult, but I don't think that this actually
captures the relevant issue particularly well.

One of the primary reasons why the RTPSEC work got started was that it
became clear that one could not safely assume that end-users would
have certificates which were verifiable by others. If we could assume
that, then life would be a lot simpler. For instance, we could have
ubiquitous S/MIME and use S/MIME signatures instead of RFC 4474.  For
that matter, we could use DTLS-SRTP without any screwing around with
fingerprints, just based on the certificates.

So, I don't think the requirement is that the protocol not constrain
the set of trust anchors. [Honestly, I'm not really sure what that
means. Does HTTPS meet this requirement?] Without trying to wordsmith
it, I would say that the requirement is that the protocol be secure
even if the users do not have credentials attested to by *any* trust
anchor.[0] That is what the relevant distinction is between self-signed
and third-party certificates.

-Ekr

[0] Incidentally, one of Dan's messages stated that he believed that
IBE would be consistent with R-12. I suppose that might be technically
true, but I think it pretty clearly does not meet the spirit of the
requirement. In order to use an IBE system, the user has to get a
private key from the PKG. This is just as inconvenient as what
we are trying to avoid with this requirement, namely forcing the
user to deal with the CA/PKG.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 May 2008 18:08:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Monday, May 05, 2008 5:01 PM
> To: Dan Wing
> Cc: 'IETF SIP List'
> Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
> 
> means. Does HTTPS meet this requirement?]

The HTTPS protocol, that exists on the wire, does not enforce (or 
know) how the certificate is validated, of course.  But if an HTTPS
client implementation required that the TLS certificate had a 
trust anchor (that is, was signed by a CA), then that HTTPS client
implementation would not meet the requirement.  Of course, almost
every deployed HTTPS client allows the user to create a whitelist of 
trusted certificates (Firefox, Safari, IE, Opera).  So, almost 
every deployed HTTPS client's implementation would meet the 
requirement.

> Without trying to wordsmith

The wordsmithing task falls to me, I suppose.  

Here is another straw man, which I think captures your sentence
above your signature and your [0] comment:

      R-CERTS:

      The media security key management protocol MUST NOT require
      using a trust anchor to validate credentials (e.g., a 
      certificate) or to obtain credentials (e.g., a private key) 
      used in the protocol.

(The "or to obtain credentials" clause is intended to cover the 
IBE case.)

-d

---

From: "Fries, Steffen (CT)" <[email-masked]>
Date: Wed, 7 May 2008 08:43:54 +0200

Hi,

thanks for the rewording Dan.  The new text is fine with me.

Ciao
	Steffen

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2008 3:09 AM
> To: 'Eric Rescorla'
> Cc: 'IETF SIP List'; 'Richard Barnes'; 'Dean Willis'; Fries, 
> Steffen (CT)
> Subject: RE: [Sip] draft-ietf-sip-media-security-requirements-05
> Importance: High
> 
> Behalf Of 
> > Eric Rescorla
> know) how the certificate is validated, of course.  But if an 
> HTTPS client implementation required that the TLS certificate 
> had a trust anchor (that is, was signed by a CA), then that 
> HTTPS client implementation would not meet the requirement.  
> Of course, almost every deployed HTTPS client allows the user 
> to create a whitelist of trusted certificates (Firefox, 
> Safari, IE, Opera).  So, almost every deployed HTTPS client's 
> implementation would meet the requirement.
> 
> > anchor.[0] That is what the relevant distinction is between 
> > self-signed and third-party certificates.
> >
> > -Ekr
> > 
> > private key from the PKG. This is just as inconvenient as 
> what we are 
> > trying to avoid with this requirement, namely forcing the 
> user to deal 
> > with the CA/PKG.
> 
> Here is another straw man, which I think captures your 
> sentence above your signature and your [0] comment:
> 
>       R-CERTS:
> 
> (The "or to obtain credentials" clause is intended to cover 
> the IBE case.)
> 
> -d
> 
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 May 2008 01:58:05 -0500

Y'all make sure you're happy with this, as this draft supposedly  
addresses everything received in WGLC . . .

so it's about ready to be a "done deal" and sent to the IESG.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 May 2008 14:54:08 -0500

> (The "or to obtain credentials" clause is intended to cover the

That's something like requiring that the protocol specification be a  
protocol specification and not an operational guideline, isn't it?

We get the two very mixed up around here.

---

From: Dan York <[email-masked]>
Date: Tue, 13 May 2008 08:38:33 -0400

Dan,

>      certificate) or to obtain credentials (e.g., a private key)

Your wordsmithing is fine by me.  I also liked the discussion you  
included in section 4.9 which explains the rationale for this  
requirement more.

  	4.9. Certificates	
				
			The discussion in this section relates to R-CERTS.	
				
			On the Internet and on some private networks, validating another	
			peer's certificate is often done through a trust anchor -- a list of	
			Certificate Authorities that are trusted. It can be difficult or	
			expensive for a peer to obtain these certificates. In all cases,	
			both parties to the call would need to trust the same trust anchor	
			(i.e., "certificate authority"). For these reasons, it is important	
			that authentication mechanisms that utilize trust anchors not rely	
			exclusively on such Certificate Authority-issued certificates, but  
to	
			also allow self-signed certificates. By allowing the use of such	
			self-signed certificates, an out-of-band mechanism (e.g., manual	
			configuration) can be used to trust a peer's certificate.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Dan York <[email-masked]>
Date: Tue, 13 May 2008 08:44:03 -0400

To that end, the new URL for side-by-side differences with the -06  
draft is:

http://www.tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-04.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements-06.txt

or  in a shortened form:  http://snurl.com/28mtd

The link below to the diff with the -05 draft no longer works.

The document looks good to me,
Dan (Y. not W.)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 May 2008 10:15:27 -0700

At Tue, 13 May 2008 08:38:33 -0400,
> 			configuration) can be used to trust a peer's certificate.

I was sort of OK with Dan's original text, though I probably would have
wordsmithed it differently, but I don't agree with this discussion at all.
Any certificate system can in principle be used with self-signed certs
by doing SSH-style fingerprint exchange. The question is whether there
is a practical deployment model that actually supports this.

Consider two examples, both using TLS:

- HTTPS in the majority of cases is incompatible with manual establishment
  of peer credentials. You connect to a lot of different Web servers and
  it's not practical to obtain their certificates out of band.
- IMAP over TLS is compatible with manual establishment of peer credentials
  because you connect with only one or two servers and you already share
  a shared secret (the password) so it's at least in principle possible
  to record their cert fingerprint. This is also why SSH works.

So, this isn't fundamentally an issue of protocol encoding (as Richard
has observed) but rather of the context in which the protocol is embedded.

So, I would rewrite this section as follows:

     On the Internet and on some private networks, validating another
     peer's certificate is often done through a trust anchor -- a list
     of Certificate Authorities that are trusted. It can be difficult
     or expensive for a peer to obtain these certificates. In all
     cases, both parties to the call would need to trust the same
     trust anchor (i.e., "certificate authority"). For these reasons,
     it is important that the media plane key management protocol
     offer a mechanism that allows end-users who have no prior
     association to authenticate to each other without acquiring
     credentials from a third party trust point. Note that this does
     not rule out mechanisms in which servers have certificates and
     attest to the identities of end-users.

And since I'm in the writing business, I would adjust R-CERTS as follows:

      The media security key management protocol MUST NOT require
      that end-users obtain credentials (certificates or private
      keys) from a third-party trust anchor.
		 
-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 May 2008 10:29:48 -0700

> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Tuesday, May 13, 2008 10:15 AM
> To: Dan York
> Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; 'Fries, 
> Steffen (CT)'; 'Dean Willis'

But sometimes you have to.  And, fortunately, almost every HTTPS-capable
client allows you to accept a certificate that isn't signed by a 
CA that the HTTPS client trusts.  

For example, Firefox 3.0b5 complains about both of these certificates 
for different reasons:

  https://www.softarmor.com
  https://www.verisign.net

>       keys) from a third-party trust anchor.

Thanks.  I will wait a few days for additional comments.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 May 2008 11:13:37 -0700

At Tue, 13 May 2008 10:29:48 -0700,
>   https://www.softarmor.com

Agreed, which is why I said "a majority" instead of all.

There are certainly cases in which HTTPS can be safely used with
manually verified server credentials in the face of active attack, but
they're the exception, not the rule. The basic assumption of the
active attack protection in HTTPS is that the client can verify the
server's certificate based purely on the URI and a list of trust
anchors. Had it been suggested that the client had to get a
certificate out of band for every server he wanted to communicate
with, this would have been (rightly) criticized as unscalable.

-Ekr

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 May 2008 20:25:25 +0100

Ekr,

Yes, I too was getting a little bit uncomfortable with saying you don't
need a trust anchor, because without some trust anchor (at least for the
server) authentication isn't achievable. So I like your proposed words.

John

> Sent: 13 May 2008 18:15
> Cc: 'IETF SIP List'; Fries, Steffen (CT); Dan Wing; 'Dean Willis'

---

From: "Fries, Steffen (CT)" <[email-masked]>
Date: Wed, 14 May 2008 12:05:09 +0200

Hi Eric,

your proposal is fine with me. I just have one point I would like to
change. Your current proposal is restricted to media plane key
management protocols. I think the text you proposed holds for both
(media and signaling) so I would suggest to just state "key management
protocol" instead of "media plane key management protocol" in section
4.9

Ciao
	Steffen

> Sent: Tuesday, May 13, 2008 7:15 PM
> To: Dan York
> Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; Fries, 
> Steffen (CT); 'Dean Willis'
> I was sort of OK with Dan's original text, though I probably 
> would have wordsmithed it differently, but I don't agree with 
> this discussion at all.
> Any certificate system can in principle be used with 
> self-signed certs by doing SSH-style fingerprint exchange. 
> The question is whether there is a practical deployment model 
> that actually supports this.
> 
> 
> So, this isn't fundamentally an issue of protocol encoding 
> (as Richard has observed) but rather of the context in which 
> the protocol is embedded.
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 19 May 2008 15:04:00 -0400

With respect to the proposed text for R-CERTS, I agree with Dean that 
this doesn't seem like a requirement on protocols, but on how protocols 
are operated.  The set of trust anchors that peers choose is an 
operating policy choice of those peers, not an issue of protocol. 
Perhaps you could put some operating recommendations in the explanatory 
section, but I don't think this issue belongs in the requirements for 
the protocol.

One minor technical issue with the explanatory text: Both parties don't 
need to trust the same trust anchor, but each peer has to have a trust 
anchor that can be used to validate the other.

--RLB

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 May 2008 15:07:00 -1000

> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Monday, May 19, 2008 9:04 AM
> To: Eric Rescorla
> Cc: Dan York; 'IETF SIP List'; 'Fries, Steffen (CT)'; Dan 
> Wing; 'Dean Willis'

It is possible to have a protocol without a trust anchor.  MIKEY-PSK and ZRTP
are two examples of protocols without trust anchors.

-d

> self-signed certs
> (as Richard