Subject: Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal]

From: Sean Turner <[email-masked]>
Date: Wed, 29 Aug 2018 21:34:34 -0400

> On Jul 23, 2018, at 15:46, Toerless Eckert <[email-masked]> wrote:
> 
> Thanks, Sean
> 
> Let me add the LAMPS working group mailing list so we have more eyes on this.
> [Bcc anima WG mailing list so WG members interested in this disus can subscribe to LAMPS
> WG mailing list ([email-masked]) ]
> Inline replies/Q's to your analysis at the end of this mail.
> 
> To repeat and expand the goal of this discussion from what i was saying that
> the LAMPS mike in IETF102:
> 
> - In ANIMA draft-ietf-anima-autonomic-control-plane (ACP), we use EST (RFC7030)
>  to renew certificates. We would like to make installations with short-lived
>  certificates work reliable, but devices may be disconnected longer than
>  the short-lived time, so renewal may only happen after the cert is expired.
> 
> - In the ANIMA WG, we seem to not be clear on the rules for renewing expired certs.
>  RFC7030 section 3.3.2 sounds as if it mandatory for the EST server to
>  validate the client certificate according to RFC5280, so we where concluding
>  that an expired client certificate might not be something that the client
>  could use if he wanted to comply to all IETF PKIX regulations.
> 
>  [ technically it would of course be fine to us the expired client certificate,
>  and it might be necessary to use it because for renewals, the certificate
>  to be renewed must be carried in the TLS authentication (if i understand it
>  correctly, it would not be re-signaled inside the EST connection because
>  the EST server wants to have prof of posession of the cert by the client,
>  and thats done by TLS and does not need to be duplicate). ]
> 
> - Yaron reminded me that in draft-ietf-acme-star certificates renewed certificates
>  are not handled as an entity that requires authentication of the recipient
>  but instead something that can be pre-created and cached in various places
>  to overcome problems with nomadic connectivity. This to me looks like
>  quite different from the approach by EST.
> 
> - My thinking is somewhat in the middle between what i think EST says and what
>  draft-ietf-acme-star says:
> 
>  - In EST, you do want identification with the pre-existing (expired) certificate.
>  - The proof of posession of the expired certificate can help the registrar
>    to determine aliveness of the client and reset any policy that could exist
>    to determine whether the client is dead (after a long enough period of time)
>    and stop reneweing certificates.
>  - The proof of posession is also necessary IMHO when rekeying is required.
> 
> - Which brings us back to Seans analysis of existing PKIX texts:
>  (inline)
> 
> On Mon, Jul 23, 2018 at 08:08:10AM -0400, Sean Turner wrote:
>> Toreless,
>> 
>> I do not believe there is any prohibition against the use of expired or even revoked certificates for renew/rekey in the PKIX suite of RFCs.
> 
> That wold be great.
> 
>> The path validation algorithm in 5280 does consider whether the certificate is revoked/expired, but does hard fail on that status.
> 
> But that would contradict your above statement, would it not ? With RFC7030
> 3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ?
> 
>> There???s nothing in the management protocols 2986 (PKCS#10), 5272 (CMC), and 4210 (CMP) about it either.
> 
> Ok, so we can ignore those docs ;-)
> 
>> But, the real reason it might be allowed is based on the CP (Certificate Policy) and that follows 3647; this RFC does have sections on "Identification and authentication for re-key after revocation???; I say ???might??? here because it is a policy decision (some CPs I???ve written allow it some do not).
> 
> Ok, so RFC3647 does seem to not describe the case of a purely 
> expired certificate, but just the re-keying of a certificate that
> was revoked, and even in that case it would be permitted based
> on a policy, so it would be ok.
> 
> Seems to leave 5280 as the existing doc standing in the way ?
> If so, how to most easily fix this ?

I think what you’re after is an explicit statement that says you’re free to use an expired certificate to request a new certificate? If you’re looking for that to be added to RFC 5280 I’d say good luck because it’s policy specific thing.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 29 Aug 2018 21:43:07 -0400

> 3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ?

I mixed a couple up a couple of things here.  The path validation will return a fail if the certificate validity period does not include the current time.  Most applications I know of throw a warning and don’t hard fall on this, e.g., the signed message is still displayed to the user.

spt

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Aug 2018 10:43:09 -0400

> I think what you’re after is an explicit statement that says you’re
    > free to use an expired certificate to request a new certificate? If
    > you’re looking for that to be added to RFC 5280 I’d say good luck
    > because it’s policy specific thing.

I think that what we want to do is write a Security Considerations for
renewing certificates using EST with an expired certificate as
authentication.    We need to outline what kinds of policy might be required,
and when it would be approrpriate not to accept specific certificates, or
when it might be appropriate to accept no expired certificates (perhaps for an
interval of time).  Or just how old (as a percentage of cert life) is too
old.

I think that the threat case here is that devices are inappropriately
disposed of (vulnerable to dumpster diving or ebay acquisition), with the
assumption that the credentials are old and do not need to be wiped.
Probably there are other threat cases that I have not thought of, and I think
that the goal would be to write the threats down... ideally to give them
names.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Thu, 30 Aug 2018 10:25:00 -0700

One of the issues that you need to make sure to include is that revocation information must be kept by the EST server until the point in time that the expired certificate would not be permitted to be used for authentication.  There is currently on a requirement that this information be kept by the server until "the first CRL after the certificate expired as been issued."  

Jim

> -----Original Message-----
> From: Spasm <[email-masked]> On Behalf Of Michael Richardson
> Sent: Thursday, August 30, 2018 7:43 AM
> To: Sean Turner <[email-masked]>
> Cc: [email-masked]; [email-masked]; Toerless
> Eckert <[email-masked]>
> Subject: Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re:
> Sean: Permissibility of expired cert renewal]
> 
> 
> I think that what we want to do is write a Security Considerations for renewing
> certificates using EST with an expired certificate as
> and when it would be approrpriate not to accept specific certificates, or when it
> might be appropriate to accept no expired certificates (perhaps for an interval
> of time).  Or just how old (as a percentage of cert life) is too old.
> 
> I think that the threat case here is that devices are inappropriately disposed of
> (vulnerable to dumpster diving or ebay acquisition), with the assumption that
> the credentials are old and do not need to be wiped.
> Probably there are other threat cases that I have not thought of, and I think that
> the goal would be to write the threats down... ideally to give them names.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 30 Aug 2018 14:54:41 -0400

> On Aug 30, 2018, at 13:25, Jim Schaad <[email-masked]> wrote:
> 

Mike,

If you do that then I think you’ll be good to go.

spt

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Aug 2018 17:18:48 -0400

mcr> I think that what we want to do is write a Security Considerations for renewing
mcr> certificates using EST with an expired certificate as
mcr> authentication.    We need to outline what kinds of policy might be required,
mcr> and when it would be approrpriate not to accept specific certificates, or when it
mcr> might be appropriate to accept no expired certificates (perhaps for an interval
mcr> of time).  Or just how old (as a percentage of cert life) is too old.
mcr>
mcr> I think that the threat case here is that devices are inappropriately disposed of
mcr> (vulnerable to dumpster diving or ebay acquisition), with the assumption that
mcr> the credentials are old and do not need to be wiped.
mcr> Probably there are other threat cases that I have not thought of, and I think that
mcr> the goal would be to write the threats down... ideally to give them names.

On Aug 30, 2018, at 13:25, Jim Schaad <[email-masked]> wrote:
> One of the issues that you need to make sure to include is that revocation
> information must be kept by the EST server until the point in time that the
> expired certificate would not be permitted to be used for authentication.
> There is currently on a requirement that this information be kept by the
> server until "the first CRL after the certificate expired as been issued."

That's a very good point.

> If you do that then I think you’ll be good to go.

okay.

Toerless, are we trying to put this into draft-ietf-anima-autonomic-control-plane ?
If so, I'll attempt to draft something that fits into that document.

If it belongs somewhere else, then please tell me.