Subject: Re: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements

From: Dan York <[email-masked]>
Date: Fri, 2 May 2008 05:46:00 -0400

Dan,

On Apr 21, 2008, at 2:22 PM, Dan Wing wrote:

> During WGLC an objection was raised about R-CERTS in
> draft-ietf-sip-media-security-requirements.  I currently have  
> proposals for:
>
>  * reverting to the R12 text
>  * sticking with R-CERTS text
>  * removing the text completely
>
> I would like to understand what people want this requirement to  
> *mean* -- does
> it say what you think it should say?  Does it miss some aspect of
> signing/certificates that is important?

DY> I think this is an important requirement in that it allows the use  
of self-signed certificates.  If I recall previous discussions  
correctly, the major concern was that we didn't want to get in a  
situation where in order to use a key management protocol all parties  
were *required* to obtain certificates signed by a formal Certificate  
Authority.   We wanted any solution to allow the optional use of self- 
signed certs for various instances where CA-signed certs might not be  
appropriate or necessary.

DY> So I think the *intent* of the requirement - as I understand it -  
is still important to capture.  What about merging R12 and R-CERTS by  
simply replacing the "CA-issued" with "3rd-party-signed", as in:

   R-CERTS:  If the media security key management protocol
         employs certificates, it MUST be able to make use of both
         self-signed and 3rd-party-signed certificates.

DY> Or is that muddying things up even more?

My 2 cents,
Dan

>
>
> -----
>
> Details:
>
> In draft-ietf-sip-media-security-requirements-00 and -01, we had:
>
>   R12:  The media security key management protocol MUST NOT
>         require 3rd parties to sign certificates.
>
> in draft-ietf-sip-media-security-requirements-02, this was renamed  
> to R-CERTS
> and also had its text change to:
>
>   R-CERTS:  If the media security key management protocol
>         employs certificates, it MUST be able to make use of both
>         self-signed and CA-issued certificates.  As an alternative,
>         the media security key management protocol MAY make use of
>         "bare" public keys.
>
>
> Here is how some key management systems would fare with the original  
> R12 text:
>
>  * RFC4474 would comply -- because RFC4474 allows both self-signed
>    certificates and allows CA-signed certificates (reference end of
>    Step 1 of Section 6 of RFC4474).  One might reasonably expect most
>    deployments will use CA-signed certificates.
>
>  * OpenPGP certificates (if someone were to use it for SRTP
>    keying) would comply -- because R12 allows you to sign your own
>    key and does not require someone else sign your key.  One might
>    expect most deployments would include signatures by other
>    people (3rd parties).
>
>  * ZRTP would comply -- because there are no 3rd party signatures
>    whatsoever.
>
>  * MIKEY-RSA complies -- because it allows self-signed certificates
>    (reference the first bullet of Section 4.3.2 of RFC3830).
>
>  * Identity-Based Encryption (if someone were to use it for SRTP
>    keying) would comply -- because IBE uses 'bare' public keys.
>
>
> and with the R-CERTS text:
>
>  * RFC4474 would comply (same reason as R12).
>
>  * OpenPGP certificates (if someone were to use it for SRTP keying)
>    would not comply -- because R-CERTS allows you to sign your own
>    key, but only mentions Certificate Authorities as 3rd party
>    signers; OpenPGP does not have 'certificate authorities'.
>
>  * ZRTP would comply (same reason as R12).
>
>  * MIKEY-RSA complies (same reason as R12).
>
>  * Identity-Based Encryption (if someone were to use it for SRTP
>    keying) would comply (same reason as R12).
>
> -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

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

_______________________________________________
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: Richard Barnes <[email-masked]>
Date: Fri, 02 May 2008 09:18:50 -0400

Hi Dan,

Response below...

> If I recall previous discussions  
> Authority.   

Yes :)

The issue here is that "self-signed" certificates and "3rd-party-issued" 
certificates are indistinguishable -- in order to be an issuer for a 
certificate (including itself!) a certificate MUST be a CA certificate, 
so all self-signed certs are CA certs.

And that means that there's no technical means to distinguish between 
"self-signed" certs and "3rd-party-issued" certs, so any protocol that 
tried to would be non-sensical regardless of this requirement.

Really, the issue of which parties are trusted sign certificates is an 
issue of local authorization policy, not of protocol design.  Regardless 
of the data items carried in the protocol, it is up to the communicating 
peers to decide which certificates are acceptable and which aren't.

That means that this requirement has no effect as a selector among 
protocols (no protocol would violate it), and it creates precisely the 
confusion that you have described, namely that the question of which 
certificates are authorized signers is one of protocol design, not local 
policy.  This is why I think that the requirement should just be 
removed: It's a no-op technically, and it creates confusion.

--Richard

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 May 2008 10:07:45 -0700

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Friday, May 02, 2008 6:19 AM
> To: Dan York
> Cc: Dan Wing; 'SIP IETF'
> Subject: Re: [Sip] R-CERTS in 
> draft-ietf-sip-media-security-requirements
> 
> Hi Dan,
> 
> Response below...
> 
> "self-signed" certs and "3rd-party-issued" certs, so any 
> protocol that tried to would be non-sensical regardless of 
> this requirement.
>

Yes, that is what we want R-CERTS to say.

Firefox 3.0b5 can distinguish between the certificates signed by
https://www.softarmor.com and https://sourceforge.net, because
the first is signed by a CA that Firefox has never heard of
(ca.softarmor.com) and the second is signed by a CA that Firefox
has in its trust list (geotrust.com).

On the wire, I agree it is impossible to tell if one or both
of those signers is on Firefox's trust list.

What R-CERTS is trying to explain is that we don't want to *rely*
on a list of trusted CAs to be carried around.  Rather, the text
is trying to say that we want implementations to allow building
their own list of trusted certificates.  That is, we want the 
protocol and the implementation to be able to do something 
functionally similar to Firefox's dialog box that shows
the certificate and asks if you want to allow it, or allows
you to pre-load a configuration file with certificates you
trust, etc. -- doing so allows us to avoid relying on everyone 
in the world using some a-priori-agreed upon list of "trusted CAs".

> removed: It's a no-op technically, and it creates confusion.

Perhaps it should dictate local policy, somewhat along the lines
of:

<strawman>

  R-CERTS:

  Local policy MUST permit a mechanism for an authorized party to 
  install trusted certificates.  Local policy MAY also use 
  trusted CAs.

</strawman>

-d

---

From: Dan York <[email-masked]>
Date: Fri, 2 May 2008 13:08:19 -0400

Richard,

On May 2, 2008, at 9:18 AM, Richard Barnes wrote:

> The issue here is that "self-signed" certificates and "3rd-party- 
> issued" certificates are indistinguishable -- in order to be an  
> issuer for a certificate (including itself!) a certificate MUST be a  
> CA certificate, so all self-signed certs are CA certs.

DY> Okay, so that is technically true, although perhaps we need to  
clarify the thinking around a "CA cert".  Let's call a spade a spade  
and spell out this issue like this:

DY> We don't want a key exchange mechanism that absolutely requires  
endpoints to have to buy potentially expensive certs from central CAs  
simply in order to communicate.  It is a requirement that any media  
key exchange mechanism allow the use of self-signed certs.

DY> That's the net of it.  And while all the *current* proposals for  
key exchange comply with that idea, I think we need to state that in  
our requirements because there undoubtedly will be future proposals  
for key exchange that may look at these requirements.

DY> While I personally like the idea of using certs that can be traced  
back to central CAs as is done in SSL/TLS today, I also think we need  
self-signed certs for academic usage, for testing/labs, for private  
networks, for environments that don't need the central authentication,  
for startups with no money, etc., etc.

> protocols (no protocol would violate it), and it creates precisely  
> the confusion that you have described, namely that the question of  
> which certificates are authorized signers is one of protocol design,  
> not local policy.  This is why I think that the requirement should  
> just be removed: It's a no-op technically, and it creates confusion.

DY> I guess I could see the possibility of a "protocol" being created  
where it was mandated that the endpoints had to do a check of a cert  
against central public CAs.  That's not what I think we want.    
Perhaps I am using a wider definition of a "protocol" than you are.

Regards,
Dan

---

From: Richard Barnes <[email-masked]>
Date: Fri, 02 May 2008 17:11:22 -0400

> against central public CAs.  That's not what I think we want.   Perhaps 
> I am using a wider definition of a "protocol" than you are.

Ah, that gives me an idea.  What you're trying to rule out is a protocol 
that says "You MUST only accept a cert that chains to an issuer X" 
(where X=Verisign, for example).  What this requirement is really saying 
is that the protocol needs to stay out of the way of the policy.

So how about this for a requirement:

R-CERTS:
The media security key management protocol MUST NOT constrain the set of 
certificates that can be used as trust anchors in certificate verification.

--RB

---

From: Richard Barnes <[email-masked]>
Date: Fri, 02 May 2008 17:13:31 -0400

Dan,

I think your straw-man has it backwards.  Local policy isn't subject to 
standardization, so you can't write a requirement on it.  But what you 
can do is say that the protocol can't constrain local policy in certain 
ways (e.g., require certain keys to be trust anchors).  See my email to 
Dan Y for a concrete suggestion for a rewording.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 02 May 2008 17:16:34 -0400

Oops, minor revision to please the cert police (who will notice that 
trust anchors are not certificates).

R-CERTS:
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.

--RB

---

From: Dean Willis <[email-masked]>
Date: Sat, 03 May 2008 01:42:30 -0500

> trust anchors that a peer can use to validate certificates used in the 

I like this one better.

--
dean

---

From: "Fries, Steffen (CT)" <[email-masked]>
Date: Mon, 5 May 2008 08:29:57 +0200

Hi Richard,

I like the wording of this requirement as it covers the different types
we had in mind to address

Ciao
	Steffen

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Barnes
> Sent: Friday, May 02, 2008 11:17 PM
> To: Dan York; 'Dan Wing'; IETF SIP List
> Oops, minor revision to please the cert police (who will 
> notice that trust anchors are not certificates).
> 
> R-CERTS:
> 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.
> 
> --RB
> 
> 
> 
> Richard Barnes wrote:
> > Ah, that gives me an idea.  What you're trying to rule out is a 
> > protocol that says "You MUST only accept a cert that chains 
> to an issuer X"
> > (where X=Verisign, for example).  What this requirement is really 
> > saying is that the protocol needs to stay out of the way of 
> the policy.
> > 
> > The media security key management protocol MUST NOT 
> constrain the set 
> > of certificates that can be used as trust anchors in 
> certificate verification.
> > 
> > 
> > --RB
> > 
> > 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
> > 
> > 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

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

Works for me.  Thanks for the wording!

I will publish -05 shortly, which will include this revised wording for
R-CERTS.

-d

> Sent: Friday, May 02, 2008 2:17 PM
> the set of 
> constrain the set of