Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Oct 2014 10:18:16 +0000

Erik Andersen <[email-masked]> writes:
>Simple Certificate Enrollment Protocol (SCEP) (
>http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf)
>appears to be widely used and implemented although it is specified in an old,
>expired Internet draft from 2011 that was never issued as an RFC.
>
>Why was it never issued as an RFC and why should it not be on the standards
>track?

Because it wasn't invented by PKIX.  PKIX have their own two protocols, CMP
and CMC, both of which have practically nonexistent support, and even less
interoperability.  SCEP was invented by Cisco but they're trying to disown it
in favour of another new protocol they've dreamed up with (you guessed it)
practically nonexistent support and interoperability.

Peter.

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 14 Oct 2014 07:15:15 -0400

The new protocol is documented in RFC 7030, "Enrollment over Secure
Transport". I'm not familiar enough with SCEP to know what the differences
are or if they are large; one primary reason for publishing the new
protocol was to permit algorithm update.

Mike

On Tue, Oct 14, 2014 at 6:18 AM, Peter Gutmann <[email-masked]>
wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 14 Oct 2014 13:16:37 +0200

Hi Peter,

Thanks for your quick answer.

The smart grid security folks want to use SCEP as normative reference in
their specification. In the current state of SCEP, this is probably against
the rules of IEC. It might be desirable to progress SCEP to a more official
status. That could be within PKIX as an RFC or as an ITU-T Recommendation to
be progressed very quickly. The latter might require some consent from
Cisco.

Regard,

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Peter Gutmann
Sendt: 14. oktober 2014 12:18
Til: IETF PKIX
Emne: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)

Erik Andersen <[email-masked]> writes:
>http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.
>pdf) appears to be widely used and implemented although it is specified 
>in an old, expired Internet draft from 2011 that was never issued as an 
>RFC.
>
>Why was it never issued as an RFC and why should it not be on the 
>standards track?

Because it wasn't invented by PKIX.  PKIX have their own two protocols, CMP
and CMC, both of which have practically nonexistent support, and even less
interoperability.  SCEP was invented by Cisco but they're trying to disown
it in favour of another new protocol they've dreamed up with (you guessed
it) practically nonexistent support and interoperability.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Oct 2014 13:47:18 +0200

> be progressed very quickly. The latter might require some consent from

Unfortunately none of the PKIX enrollment protocols support
E2ES (end-to-end security) so they are fairly useless for
large-scale applications, including IoT.  FIDO alliance have
(with Google's help) produced new protocols that support E2ES.

E2ES in this context means that the key-container attests
its identity/authenticity as a part of the protocol.

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 14 Oct 2014 12:36:50 +0000

On Tue, Oct 14, 2014 at 6:15 AM, Michael Jenkins <Michael Jenkins <[email-masked]> wrote:

>are or if they are large; one primary reason for publishing the new protocol
>was to permit algorithm update.

And let's not forget XKMS (W3C), KMIP (OASIS), PCAS (TCG), and at least two Microsoft protocols [1].  Did I miss anyone?  :)

ObXkcdRef: http://xkcd.com/927/

And as far as SCEP being a "old and clunky," IMHO it's more accurate to say "broken in many implementations because of subtle design assumptions."  (Ref: http://www.css-security.com/wp-content/themes/css/scep/SCEP_and_Untrusted_Devices.pdf) 

-- T

[1] I'm actually willing to give TCG a pass on re-inventing enrollment because their threat model is such that the certificate and it's association with an endorsement key have to be kept private from eavesdroppers, and I'm not convinced you could do that with any other extant enrollment protocol.  That doesn't excuse TCG for their other standards abuses, however.  :)

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 14 Oct 2014 10:31:02 -0400

> be progressed very quickly. The latter might require some consent from
Related:
The Use of the Simple Certificate Enrollment Protocol (SCEP) and
Untrusted Devices,
http://www.css-security.com/wp-content/themes/css/scep/SCEP_and_Untrusted_Devices.pdf.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Oct 2014 08:21:23 -0700

> Thanks for your quick answer.

Which, unfortunately, was wrong. SCEP's lack of standardization was not because PKIX had their own protocols: it was because it was a quick hack by Cisco for one scenario (IPsec certs) and people kept pointing out flaws that were only slowly fixed. That is, Cisco never wanted SCEP to be standardized because doing so would mean that they had to change their SCEP code to match the standardized version.

> their specification.

Which SCEP? The on-the-wire protocol changed from draft to draft, and I believe that the final draft does not match Cisco's implementation. If you point at one draft, you will have terrible interoperability, and what interoperability you get will be to a flawed protocol. See below.

On Oct 14, 2014, at 7:09 AM, Stephen Kent <[email-masked]> wrote:

> Cisco developed and promoted SCEP without submitting it to the IETF, to compete
> with the cert management protocols that other vendors were developing. This
> end run of IETF process was not well received. I had first hand knowledge
> of how Cisco pushed SCEP because I served as CT for CyberTrust, a Web PKI
> CA, during this time.

Cisco consistently published drafts of SCEP without "submitting it to the IETF" because Cisco and Cisco's competitors didn't want to deal with having to change their codebases. This is a perfectly acceptable practice in the IETF, even though you doesn't like it in this case. Just to be clear: many of Cisco's competitors in the IPsec market were quite happy that Cisco bothered to document their proprietary protocol so that they could at least be bug compatible with Cisco. IIRC, there were at least four separate SCEP implementations at the last large IPsec Bakeoff that worked well with each other.

> Several later Cisco staff approached the IETF asking that SCEP be published as an RFC.
> They agreed that it could be labelled Historic.

There was also a discussion of labeling it Informational, because that was a more accurate description: it was a vendor-proprietary solution that was being documented so other vendors could interoperate if they wanted to, even though the solution was kinda sucky.

> (It did not offer alg agility, a
> feature that we required of all security protocols by that time.)

It did not offer a lot of stuff that a good cert enrollment protocol should offer; that wasn't the point.

> We were told
> that Cisco just wanted a stable reference for it, nothing more, and that they agreed
> it should be replaced with a more modern protocol.

Yes.

> So, Tim Polk and I re-wrote the seriously-flawed I-D that they had been repeatedly
> published (to keep it alive) as an individual submission.  We got very close to a
> reasonable version that could be published as Historic. Then, during lunch at an
> IETF meeting, a different Cisco staff member showed up to discuss the status of SCEP.
> At this lunch meeting he noted that the reason Cisco wanted an RFC number for SCEP
> (irrespective of the status)  was to be able to cite it in a submission to 3GPP!
> Apparently, this staff member had not been instructed to lie about their real intent.
> That  ended the discussion  of SCEP as an RFC.

Nice word, "lie". It indicates that everyone at Cisco has the same intent, and they are all instructed in what to say in public. Anyone working with the Cisco IPsec team at the time knows that such an assertion is demonstrably false, even though it makes for good drama here.

> Subsequently, another Cisco staff member came forward wanting to pursue a replacement
> for SCEP, with up-to-date features and and a broader focus.

This too is inaccurate because he wasn't "another" Cisco staff member, he was the one who had be stuck with maintaining SCEP in its waning years. He had first-hand understanding of where SCEP sucked and what to do about it.

> This proposal went
> through numerous revisions and received input from several sources. It became EST and
> it was issued as an RFC from PKIX.

If the "smart grid security folks" want to reference a well-written certificate enrollment protocol, they should stay the heck away from SCEP and point to EST.

--Paul Hoffman

---

From: "Sill, Alan" <[email-masked]>
Date: Tue, 14 Oct 2014 16:21:43 +0000

> If the "smart grid security folks" want to reference a well-written certificate enrollment protocol, they should stay the heck away from SCEP and point to EST.

With this in mind, I would appreciate some informed commentary from this group on the article by John Foley covering this topic in the September 2014 issue of Linux Journal:

http://www.linuxjournaldigital.com/linuxjournal/september_2014/?pg=62&pm=2&u1=friend

(You can close the subscription pop-in window to view the entire article, as it is an open article.)

It refers to a Cisco test server, but otherwise appears to be a very general technical treatment on implementing EST.

Thanks,
Alan

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2014 12:29:16 -0400

Paul,

> There was also a discussion of labeling it Informational, because that was a more accurate description: it was a vendor-proprietary solution that was being documented so other vendors could interop…
The discussion about a label of historic involved the PKIX chairs, the 
cognizant
Sec AD, and the IETF chair. I think this superseded the discussion of an 
informational
label.
> Nice word, "lie". It indicates that everyone at Cisco has the same intent, and they are all instructed in what to say in public. Anyone working with the Cisco IPsec team at the time knows that such…
I agree that Cisco may not have coordinated the rationale we were given 
for publishing
SCEP, but we got the same story from multiple individuals in a few 
different
parts of the organization. As an outsider, I think that "lie" is an 
appropriate characterization.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Oct 2014 09:31:15 -0800

On 10/14/14 8:29 AM, Stephen Kent wrote:
>> Nice word, "lie". It indicates that everyone at Cisco has the same 
>> intent, and they are all instructed in what to say in public.
>> Anyone working with the Cisco IPsec team at the time knows that
>> such an assertion is demonstrably false, even though it makes for
>> good drama here.

> I agree that Cisco may not have coordinated the rationale we were
> given for publishing SCEP, but we got the same story from multiple
> individuals in a few different parts of the organization. As an
> outsider, I think that "lie" is an appropriate characterization.

I was at Cisco at the time.  That is not correct.  Interest in
bring SCEP to the IETF waxed and waned and at different points
different people showed different levels of interest in working on
getting the spec through the IETF process.  Nobody was ever instructed
to lie - I'd be hard-pressed to say that anybody was instructed to
do much of anything in terms of publishing SCEP.  My understanding
of the 3gpp situation was that someone at Cisco wanted to
take SCEP to 3gpp and that's what motivated a renewed interest
in publishing it as an informational document (within Cisco; whether
the responsible IETF people were more interested in publishing it
as an historic RFC is largely orthogonal to that).

Without actually talking with the people involved all we can go
on is what we see.  It's a black box problem.  Fabricating a narrative
and making judgments based on that fabricated narrative strikes me
as profoundly unhelpful.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2014 11:54:32 -0400

Melinda,
> to lie -
I don't recall saying they were instructed.
> I'd be hard-pressed to say that anybody was instructed to
> do much of anything in terms of publishing SCEP.
ibid.
> My understanding
The individual who showed up at PKIX meetings to push for publication
was someone who had no visible activity in PKIX prior to his arrival
at a WG meeting.

The individual who declared the intent to use the RFC to submit SCEP
to 3GPP was different, and was different from the individuals who had
previously met with us on the topic.

So, yes, it is possible that these two individuals and the others who
engaged with the IETF requesting publication of SCEP had completely
different agendas.

The real issue is that the argument put before PKIX and the Sec ADs,
repeatedly, was that an RFC was needed to provide a stable reference 
document
for SCEP. This is an absurd assertion; Cisco was capable of publishing its
spec on a public Cisco web site, thus making it available to anyone who 
needed it.
Internet search was already adequate (in that time frame) for anyone 
interested
in the spec to find it on such a site. If Cisco vanishes, the doc will 
have been
archived and thus remain available for many years.

The only credible reason for publishing an RFC describing SCEP (with any RFC
label) was to have an RFC number that one could use to claim the 
imprimatur of
the IETF. Whether the RFC number is to be used to cause another SDO to 
accept
the protocol, or for marketing purposes, is irrelevant. Such behavior is 
what
caused me to use the term "lie."

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Oct 2014 09:03:40 -0700

On Oct 21, 2014, at 8:54 AM, Stephen Kent <[email-masked]> wrote:
> repeatedly, was that an RFC was needed to provide a stable reference document
> spec on a public Cisco web site, thus making it available to anyone who needed it.
> Internet search was already adequate (in that time frame) for anyone interested
> in the spec to find it on such a site. If Cisco vanishes, the doc will have been

If you want to change the rules for how RFCs are published, it might be better done so as a participant in an IETF-wide discussion, not as a WG chair who is preventing someone from using the process correctly. Otherwise, it simply looks like you are wielding power just to seem powerful.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2014 19:39:14 -0400

Paul,

The rules for what gets published as an RFC are flexible. Contrary to 
your assertion
I did not change the rules. Decisions about publishing documents 
developed outside
of WGs are based on inputs from relevant WG chairs (if any), and the 
IESG. The RFC
editor of the relevant stream has the final say in such matters.

In my role as PKIX chair I expressed my view that the cited 
justification for
publishing SCEP was not credible, and shared that view with the Sec ADs 
and the
IETF chair, i.e., I provided my input. However, I could not veto 
publication
unilaterally as you seem to have suggested. If the IESG or the cognizant 
RFC Editor
decided that the spec should be published as Informational or Historic 
they could
have done so.

In the end I suspect that IESG members involved with the discussion were 
as upset
as I by the disclosure that at least one Cisco staff member had an 
ulterior motive
for requesting publication.

Steve

> On Oct 21, 2014, at 8:54 AM, Stephen Kent<[email-masked]>  wrote: