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

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 7 Nov 2014 23:03:40 +0000

On Oct 29, 2014, at 6:35 AM, Peter Gutmann <[email-masked]> wrote:

> I've spent the time since the last exchange of messages on this thread talking
> to various SCEP users over their requirements.  It turns out that the figure
> I'd previously posted, of half a billion SCEP devices in active use, was
> rather an underestimate.  SCEP seems to be pretty much the universal device-
> provisioning protocol for non-PC/laptop devices, including mobile phones,
> SCADA devices, gaming machines, ATMs, firewalls, and so on.  It's also been
> described to me as the standard BYOD provisioning protocol, its use for this
> being so widespread that Server 2012 even added new, extra capabilities for
> dealing with BYOD use via SCEP (Windows Server 2008 and 2012 are pretty much
> the standard server implementations for dealing with this sort of thing).  As
> one person told me, "if a device speaks anything, it'll speak SCEP".
> 
> So, no matter how much Cisco would like to forget about it, it's extremely
> widely used, and there's no sign that this is going to change in the future.
> To paraphrase something someone said many years ago about IBM, "SCEP isn't the
> competition, it's the environment”.

Agreed! We can’t “forget” about it. This is why we paid so much attention to the process flow of SCEP when designing EST to insure minimal pain. 
We also need to be able to move forward to suite-b and better client authentication methods. Thus the reason we had to describe something beyond SCEP (which can’t support these improvements). This led to the specific CMC profile that is EST. 

> 
> To that end I'd like to request that the SCEP authors give me (or someone else
> who cares about it, e.g. one of the JSCEP folks) change control over the
> document so that we can finally get this published.  I submitted a list of
> changes for the current doc ages ago but things seem to have stalled since
> then (the changes were minor things that have come up in real-world usage,
> clarifications to the doc, places where ~15-year-old remnants still exist next
> to current ones, and just a general cleanup of the neglect that it's had for
> the last decade or so, it still talks about MD5 and single DES for example,
> but doesn't mention that newfangled AES thing that everyone's talking about).
> 
> Given that it's been more or less abandoned by Cisco, I'd like to finish the
> editing for it and finally get it published as an RFC so that the vast number
> of devices out there using it, and that will use it in the future, have a
> fixed standard that they can refer back to.

I’ll be at IETF next week. Lets meet with any interested parties and figure out a path forward. 

A question: How is updating "half a billion SCEP devices” to a new version of SCEP any different than updating them to EST or similar?  

- max 

> Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 08 Nov 2014 06:30:22 +0100

On 2014-11-08 00:03, Max Pritikin (pritikin) wrote:
<snip>

> A question: How is updating "half a billion SCEP devices” to a new version of SCEP any different than updating them to EST or similar?

The IoT folks probably already have a new solution and if they don't they won't settle for anything less than a scheme using attestation keys.

Google have recently introduced a new PKI enrollment protocol as well:
https://developer.chrome.com/extensions/enterprise_platformKeys

Anders

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 9 Nov 2014 21:47:46 -0500

On Wed, Oct 29, 2014 at 12:19 PM, Anders Rundgren
<[email-masked]> wrote:
> The only thing that could eventually replace SCEP for "devices" including
> BYOD, would be a protocol that builds on embedded attestation keys like the
> FIDO/Google U2F scheme.  Such a scheme could completely eliminate the
> reliance on enrollment passwords.
Attestation key pairs are shared across devices by a vendor to provide
anonymity (cf.,
https://fidoalliance.org/specs/fido-u2f-overview-v1.0-rd-20141008.pdf,
page 9). I don't think one of SCEP's design goals is anonymity (but
its been a while since I looked at it and NDES).

Rather, I'm pretty sure its the opposite: during provisioning, the
SCEP admin wants to know who/what is being provisioned. In this case,
the anonymity provided by the attestation key pairs is probably
unwanted; and the uniqueness provided by a challenge password is
probably desired.

I wonder how long before the attestation key pairs start showing up in
Little Black Box (https://code.google.com/p/littleblackbox/).

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Nov 2014 06:27:39 +0100

> unwanted; and the uniqueness provided by a challenge password is

You are absolutely right.  Enrolling certificates to anonymous routers etc.
would be the opposite to what you want.

The problem with PKIX protocols is that they don't provide mechanisms
for attesting keys.  BTW, I suggested this years ago.

---

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Mon, 10 Nov 2014 20:50:25 -0500

Hi all,

I read the thread for a while. I actually do remember that there was a 
presentation for SCEP and a request for that to be adopted as a working 
item in this group that was refused based on the fact that we already 
have IETF protocols for that.

If this argument till stands, than any work on this item (or its 
successor) should be informational and not WG.
However, I think it would be useful to resume a conversation about the 
status of enrollment protocols - in particular, if the current PKIX WG 
sponsored RFC are not used in the real world (maybe too complex or too 
many options?) maybe we should address the issue and work on an 
easier-to-deploy solution..??? After all, what is the use of a standard 
if nobody uses it in the real world? If that is the case, I think we 
need to be humble and admit the limits of the current standards and 
design a pattern to move forward.

It could also be that we like the status quo and leave things as they 
are today - if the majority of people are happy with what we have today.
Can we have a poll about "is there a need to review/amend/simplify PKIX 
work for certificate enrollment" ?

Max Pritikin: I would be interested to meet and talk, can you please 
include me in the discussion/meetings about this?

Last consideration: Although I am not the WG chair, and it is not my 
role, I would like to keep the discussion in check. I have the 
impression that the topic is somewhat overloaded with non-technical 
aspects and I hope we can, instead, focus on technical aspects and on 
what is needed rather than on how this was handled in the past.

Cheers,
Max

> On Nov 7, 2014, at 1:03 PM, Max Pritikin (pritikin) <[email-masked]> wrote:
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 11 Nov 2014 05:41:44 +0100

On 2014-11-11 02:50, Dr. Massimiliano Pala wrote:

If we stick to personal computing devices they are de-facto defined by only
3 giant US vendors.  They are not interested in even discussing what they
see as potentially valuable, particularly not in a public mailing list.

Anyway, none of the PKIX protocols support provisioning of two-factor
credentials (Key + PIN).  This may sound like a minor problem to fix
but such a scheme requires the protocol having the key-container as
the true end-point rather than the client/P11.  The same is valid for
key attestation.

For IoT, like smart meters there are since years back specific solutions
based on non-X.509 certificates.

When the work with EST started it was taken for granted that ASN.1,
PKCS #10 etc. would be a requirement.  However, it seems that JSON
have taken ASN.1's role for new developments also in IETF, here thinking
of the JOSE suite.

Anders

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 11 Nov 2014 20:02:36 +0000

Hi Max Pala, 

Some of the core ideas in the original SCEP draft were included into CMC (notice there is even a Cisco author shared between those two efforts). 

Unfortunately CMC lost some of the simplicity and directness of SCEP (e.g. CMC has a complex number of options). The approach didn’t really get traction and SCEP become something of a defacto standard despite its limitations. 

Those limitations are significant and as algorithm agility and other protocols have progressed SCEP is looking even more crufty/problematic then ever before. 

EST RFC7030 addresses these limitations by profiling CMC back into the simplicity original envisioned while maintaining the necessary functionality and providing a clear path for future extensibility and access to the full CMC feature set. Please take a look at it before suggesting additional work:
	http://tools.ietf.org/html/rfc7030

SCEP itself could be turned into a historic RFC purely to clarify that it is *historic* and not a work in progress. I don’t see a compelling reason to repeat this process again. 

- max

On Nov 10, 2014, at 3:50 PM, Dr. Massimiliano Pala <[email-masked]> wrote:

> Hi all,
> 
> I read the thread for a while. I actually do remember that there was a presentation for SCEP and a request for that to be adopted as a working item in this group that was refused based on the fact that we already have IETF protocols for that.
> 
> If this argument till stands, than any work on this item (or its successor) should be informational and not WG.
> However, I think it would be useful to resume a conversation about the status of enrollment protocols - in particular, if the current PKIX WG sponsored RFC are not used in the real world (maybe too complex or too many options?) maybe we should address the issue and work on an easier-to-deploy solution..??? After all, what is the use of a standard if nobody uses it in the real world? If that is the case, I think we need to be humble and admit the limits of the current standards and design a pattern to move forward.
> 
> It could also be that we like the status quo and leave things as they are today - if the majority of people are happy with what we have today.
> Can we have a poll about "is there a need to review/amend/simplify PKIX work for certificate enrollment" ?
> 
> Max Pritikin: I would be interested to meet and talk, can you please include me in the discussion/meetings about this?
> 
> Last consideration: Although I am not the WG chair, and it is not my role, I would like to keep the discussion in check. I have the impression that the topic is somewhat overloaded with non-technical aspects and I hope we can, instead, focus on technical aspects and on what is needed rather than on how this was handled in the past.
> 
> Cheers,
> Max
> 
>

---

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Tue, 11 Nov 2014 10:44:58 -1000

Max,

thanks for the reply. However, I was not blindly proposing new work - my 
proposal was not to start new work but to see if there is the need to 
revisit existing work based on considerations about deployment 
considerations across different domains (i.e., not only network 
appliances) and support for it from Internet CAs.

I take that your position is "no". However, I had the impression you 
were proposing a path forward (quoting: "I’ll be at IETF next week. Lets 
meet with any interested parties and figure out a path forward.")

As said before, if the majority agrees that the status quo is ok, that 
is fine. I had the impression that that was not the case.

Cheers,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 05:15:28 +0100

http://defensesystems.com/articles/2014/11/10/comment-can-derived-credentials-replace-cacs.aspx

A problem with current protocols including CMC, SCEP and EST is that they
don't support enrollment of two-factor credentials[1] and secure key-storage[2]
such as (indirectly) required by the US government.

Anders

1] Key + PIN
2] Through key-container attestations

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 12 Nov 2014 09:12:37 +0000

I am hear all week and willing to do a meeting. Do you have a time in mind? TH lunch maybe? 

I agree that an enrollment protocol doesn't solve the deployment considerations across multiple domains. Some of my thoughts in this area are captured in my bootstrapping key infrastructures draft and the preso in anima earlier in the week. I'd look forward to a discussion and additional input about that. 

I see these as distinct issues from "enrollment" itself - but agree the boundaries could be defined differently. 

- max

> On Nov 11, 2014, at 10:45 AM, Dr. Massimiliano Pala <[email-masked]> wrote:
> 
> Max,
> 
> thanks for the reply. However, I was not blindly proposing new work - my proposal was not to start new work but to see if there is the need to revisit existing work based on considerations about deployment considerations across different domains (i.e., not only network appliances) and support for it from Internet CAs.
> 
> I take that your position is "no". However, I had the impression you were proposing a path forward (quoting: "I’ll be at IETF next week. Lets meet with any interested parties and figure out a path forward.")
> 
> As said before, if the majority agrees that the status quo is ok, that is fine. I had the impression that that was not the case.
> 
> Cheers,
> Max
> 
>

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 10:25:25 +0100

On 2014-11-12 10:03, Max Pritikin (pritikin) wrote:
> Anders - both of these requirements can be met by these protocols.

AFAICT, end-to-end security with respect to the *key-container* is outside of all
PKIX enrollment protocols.  No CMS (Card Management System) use CMP, SCEP, EST
directly, they use other protocols for actual token provisioning/initialization.

The latter obviously doesn't work for derived credentials since these typically
are 100% on-line provisioned.  Such schemes (entirely proprietary of course...)
are widely deployed in the EU for usage by consumers.

Anders

>
> - max
>
>> On Nov 11, 2014, at 6:15 PM, Anders Rundgren <[email-masked]> wrote:
>>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 12 Nov 2014 09:03:26 +0000

- max

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 13:17:37 +0100

https://www.w3.org/2012/webcrypto/wiki/images/d/dd/CertAndKey_Management_Requirements_for_WebCrypto_microsoft.pdf

Anders

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 12 Nov 2014 18:42:01 +0100

> directly, they use other protocols for actual token provisioning/initialization.

This is not correct. I have participated in the implementation of two Card Management Systems that use CMP for smart
card initialization and provisioning. Both are operative, the first one managing over 8 million cards, the second one
over 60.000.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 12 Nov 2014 18:45:16 +0100

Anders Rundgren wrote on 12.11.2014 10:25:

> PKIX enrollment protocols.  

you have stated that several times but still I don't understand the issue. Could you please elaborate on that? What
exactly do you mean by "end-to-end security with respect to the key-container" and how should it be solved?

-- 
Johannes

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 19:11:21 +0100

> exactly do you mean by "end-to-end security with respect to the key-container" and how should it be solved?

SM (Secure Messaging) is a standard feature in cards conforming to GlobalPlatform specifications.
Neither PKIX protocols, nor PKCS #11 support SM.

What it means is that you during provisioning have like a "TLS" channel with
the key container itself so that you know that the keys actually resides in the
designated device.

Regarding how to solve it, Google have managed in record-time gather just about
everybody from platform vendors, smart card manufacturers to VISA around their
U2F-concept which *presumes* end-to-end-security provisioning.  Somewhat simplified
the cert-req is counter-signed by a built-in attestation key which for obvious
reason is only allowed to sign such data.

I guess Apple use something similar for Apple Pay.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 19:24:13 +0100

> card initialization and provisioning. Both are operative, the first one managing over 8 million cards, the second one

You always need a proxy between the card and CMP.  Such a proxy may do things
like card initialization, PIN-assignment etc.  CMP (like all PKIX protocols)
also assume that it is the client (in this case the proxy) that specifies
key algorithms since it is a strict client-server protocol.  I.e. "key agility"
with respect to the issuer (who usually have the policy) is also missing from
the PKIX plot.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Nov 2014 21:24:31 +0100

In case you want to study a protocol which was designed for this purpose
you can take a peek at:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run

anders