Subject: [saag] AD review of draft-gutmann-scep

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 13 Feb 2017 10:40:28 -0500

Hello,

I reviewed the following draft in a request to AD sponsor,
https://datatracker.ietf.org/doc/draft-gutmann-scep/  Additional
comments are welcome on the draft.  I don't think there is a better
suited list to discuss, so I am posting the review here.

Major:

1. I see the draft is marked as a proposed standard, but previous
drafts for SCEP are marked as HISTORIC with the reason explained in
the introduction of https://tools.ietf.org/html/draft-nourse-scep-23.
Can you explain why this is marked as standards track?  I'd like to
figure out the best fit.

Nits:

1. Introduction:

The following opinion sentence is not necessary as worded:
   While
   implementers are encouraged to investigate one of the more
   comprehensive alternative certificate management protocols in
   addition to the protocol defined in this specification, anyone
   wishing to deploy them should proceed with caution, and consider
   support and interoperability issues before committing to their use.

I think it'll raise objections because of the opinion aspect, which
isn't really appropriate for a standards document.

2. Section 2.1.3: s/the them/them/
   If the CA certificate(s) have not previously been acquired by the
   client through some other means, the client MUST retrieve the them
   before any PKI operation (Section 3) can be started.

3. Section 2.1.3
Is SHA-1 still really need for legacy reasons or can that be eliminated?

4. Section 2.8
Are you really still seeing use of 3DES and SHA-1 or is this old text?

5. Section 4.4
s/Whe the client/When the client/

-- 

Best regards,
Kathleen

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Feb 2017 04:45:58 +0000

Kathleen Moriarty <[email-masked]> writes:

>1. I see the draft is marked as a proposed standard, but previous drafts for
>SCEP are marked as HISTORIC with the reason explained in the introduction of
>https://tools.ietf.org/html/draft-nourse-scep-23. Can you explain why this is
>marked as standards track?  I'd like to figure out the best fit.

That's a political thing, I'll reply off-list.

>I think it'll raise objections because of the opinion aspect, which isn't
>really appropriate for a standards document.

That's not an opinion, it's just a statement of fact, the alternatives to SCEP
have proven so hard to deploy that... well, see above.  All it's doing is
explaining why SCEP continues to exist despite there being supposed
replacements.  It's actually a lot milder than what it should say, which is
that we have 15 years of experience in these things being almost impossible to
deploy in an interoperable manner.

>Are you really still seeing use of 3DES and SHA-1 or is this old text?

The MTI algorithms throughout most of the document's lifetime was MD5 and
single DES.  When I took over editing in 2015 I added AES (although several
implementations had already added it by themselves back then despite it not
being in the spec) and later SHA-256, and a handful of further vendors have
now added support for AES.  SHA-256 is less common.  Many (most?) though only
go up to 3DES and SHA-1.  The spec didn't allow AES and SHA-256 until 2015,
and since the major use of SCEP is in embedded, rollout is going to take years
if not a decade or more.  Deprecating 3DES or SHA-1 at this point would make
probably the majority of all SCEP implementations non-compliant with the spec.

>s/Whe the client/When the client/

Thanks, fixed.

Peter.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 Feb 2017 15:34:43 -0500

Hi Peter,

> That's a political thing, I'll reply off-list.

OK, I've heard a bit on this now and think HISTORIC is the best option
to go forward.  From what I understand, while there are a number of
existing implementations, there are no new ones in development.  This
is just documenting for the existing, so historic is appropriate.

Should any of the prior authors be listed as authors/editors?  It
would seem that they should be.

> probably the majority of all SCEP implementations non-compliant with the spec.

In light of news today, it would be good to deprecate SHA-1.

>>s/Whe the client/When the client/

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 26 Feb 2017 21:24:27 +0000

Kathleen Moriarty <[email-masked]> writes:

>OK, I've heard a bit on this now and think HISTORIC is the best option to go
>forward.  From what I understand, while there are a number of existing
>implementations, there are no new ones in development.  This is just
>documenting for the existing, so historic is appropriate.

Sure, that works for me.  The reason why I was hoping for standards-track is
that it's referenced in a number of other (non-IETF) standards, and I don't
know whether their attitude to downrefs is the same as the IETF one.  Can you
reference a non-standards-track doc (i.e. historic-status) from a standards-
track one?

>Should any of the prior authors be listed as authors/editors?  It would seem
>that they should be.

I think so too, but there's more politics involved.  I'll reply off-list.

(If anyone else is interested in the reasons I'm happy to give them, it's just
best not to create a public record of it).

>In light of news today, it would be good to deprecate SHA-1.

The problem with doing that, if it's done as a MUST NOT (it's already a MUST
SHA-2, MAY SHA-1), is that it would instantly make pretty much every
implementation of SCEP in existence non-compliant.  In addition it's not
really an issue, I've got the following draft text ready to add to the
security considerations:

-- Snip --

Use of SHA-1

Virtually all of the large numbers of devices that use SCEP today default to
SHA-1, with many supporting only SHA-1 with no ability to upgrade them.  This
hash algorithm is no longer regarded as secure in all situations, but as used
in SCEP it's still safe.  

There are three reasons for this, the first being that attacking SCEP would
require creating a SHA-1 collision in close to real time, which won't be
feasible for a very long time.

The second reason is that the signature over the message doesn't serve any
critical cryptographic purpose: The PKCS #10 data itself is authenticated
through its own signature, protected by encryption, and the overall request is
authorised by the (encrypted) password.  The sole exception to this will be
the small number of implementations that support the Renewal operation, which
may be authorised purely through a signature, but presumably any
implementation recent enough to support Renewal also supports SHA-2.  Any
legacy implementation that supports the historic core SCEP protocol would not
be affected.

The third reason is that SCEP uses the same key for encryption and signing, so
that even if an attacker were able to capture an outgoing Renewal request that
didn't include a password (in other words one that was only authorised through
a signature), forge the SHA-1 hash in real time, and forward the forged
request to the CA, they couldn't decrypt the returned certificate, which is
protected with the same key that was used to generate the signature.  While
<xref target="security-unnecessary"/> points out that SCEP uses unnecessary
cryptography in places, the additional level of security provided by the extra
crypto makes it immune to any issues with SHA-1.

This doesn't mean that SCEP implementations should continue to use SHA-1 in
perpetuity, merely that there's no need for a panicked switch to SHA-2.

-- Snip --

Peter.

---

From: [email-masked]
Date: Sun, 26 Feb 2017 21:57:36 -0500

Hi Peter,

Please excuse typos, sent from handheld device 

> On Feb 26, 2017, at 4:24 PM, Peter Gutmann <[email-masked]> wrote:
> 
> know whether their attitude to downrefs is the same as the IETF one.

Good, thanks.
>  Can you

Yes, we just have to call it out during IETF last call.

> I think so too, but there's more politics involved.  I'll reply off-list.

Ok, thanks.
> really an issue, I've got the following draft text ready to add to the

Thanks for the text below.  I was meaning to send a note saying it didn't matter with the draft going historic, but think your text would be a helpful addition.

I'll look at your other message.

Thank you,
Kathleen