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

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Oct 2014 13:40:01 +0000

"Miller, Timothy J." <[email-masked]> writes:

>And let's not forget XKMS (W3C), KMIP (OASIS), PCAS (TCG), and at least two
>Microsoft protocols 

None of those are really cert-enrolment protocols though...

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

I've read that before and found it a bit silly, it basically says "issuing a
certificate containing a verbatim copy of what the client asks for ('give me a
certificate that makes me a CA, and issued for google.com') can result in
unexpected rights amplification".  Well, duh.

Peter.

---

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

>None of those are really cert-enrolment protocols though...

Well, PCAS is explicitly an enrollment protocol--you send a public key, you get back a certificate--as are Microsoft's ICEnroll and the WS-Trust based enrollment protocol (Certificate Enrollment Web Services) in Server 2k8r2.  

While it's true that KMIP explicitly disclaims enrollment, it nevertheless has the features you need for enrollment and can be (mis?)used that way.  Similarly so with XKMS.  Besides, it's funnier when you include them.  :)

>unexpected rights amplification".  Well, duh.

IMHO the key point from CSS's discussion is that the SCEP authenticator doesn't actually bind to the identity to be requested or to the requestor, so you can enroll a different device than the one the RA thinks you're enrolling, or you can pass the authenticator along to an otherwise unauthorized person (or both).  This isn't a concern in a closed environment as long as you have either physical control of the devices enrolled, trusted and accountable "sponsors" acting on behalf of the non-person Subscriber, or (ideally) both.  Unfortunately in the general non-person Subscriber use case there's a scalability requirement that incentivizes over-automation and reduces accountability and control--and that opens up a hole in SCEP you can drive a truck through.   (Cue Anders again.  :)

Naturally human Subscribers can attempt the same shenanigans but there are at least the pretense of checks in those systems.  

-- T