Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

From: Ray Cheng <[email-masked]>
Date: Mon, 31 Oct 2016 15:13:39 +0000

Hi Jacob,

From: Jacob Hoffman-Andrews, Thursday, October 27, 2016 5:28 PM:
> 
> On 10/04/2016 06:11 AM, Ray Cheng wrote:
> > One way to accomplish this in the protocol is to simply add a "ca-
> extension" object to the registration object, where the "ca-extension"
> object is an array of name-value pairs of strings. For example:
> I think this makes a lot of sense, and is in the spirit of the other
> places we've intentional left hooks for CA-specific customization, like
> OOB challenges. I'm inclined to accept it.
> 
> Additionally, your experience as a commercial implementer of ACME may be
> valuable to spot places where the current protocol is lacking. For
> instance, you need an "account" field, and StartCom needs
> (https://github.com/ietf-wg-acme/acme/pull/172) a "token" field. Can we
> support those use cases natively in ACME so they don't need to be
> extensions? What do you put in the "account" field, and how do you
> authenticate the link between the ACME account and the Entrust account.
> 

We are effectively using "ca-account-id" and "ca-account-secret" fields to authenticate the link to the Entrust account. Since these fields do not currently exist in draft-03 and certbot, we are embedding them in the URL that a particular customer uses to access our ACME server.

The "external_secret"/"token" is slightly different but is also useful as an "API key" type of authentication.

Although we see value in a "ca-extension" object, we also support adding explicit fields in ACME. There are some advantages to explicit fields - one in particular is the special handling of designated secret fields by clients.

Thanks for your feedback.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 19 Nov 2016 10:08:59 +0900

Hey Ray,

We discussed this at the F2F meeting at IETF 97 last week.  The conclusion
there was that we're not going to create a special zone for CA extensions,
but rather just let CAs extend the relevant object directly.

The major risk here is collision -- if two CAs extend an object using the
same field name with different semantics.  To help avoid that, I've posted
a PR that creates registries of field names; the only requirement to add
something to the registry is that there be a specification for it somewhere.

https://github.com/ietf-wg-acme/acme/pull/211

Does that sound OK to you?  Let me know if you have any comments on the PR.

--Richard

On Tue, Nov 1, 2016 at 12:43 AM, Ray Cheng <[email-masked]>
wrote:

> We are effectively using "ca-account-id" and "ca-account-secret" fields to
> authenticate the link to the Entrust account. Since these fields do not
> currently exist in draft-03 and certbot, we are embedding them in the URL
> that a particular customer uses to access our ACME server.
>
> Although we see value in a "ca-extension" object, we also support adding
> explicit fields in ACME. There are some advantages to explicit fields - one
> in particular is the special handling of designated secret fields by
> clients.
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 19 Nov 2016 08:22:56 +0100

It is worth noting that “external_secret”, “ca-account-secret”, and “token” are all secret bearer tokens
and, as such, offer *significantly* less security than the default ACME mechanisms, and in some cases 
may defeat the purpose of having account keys.

I can see that different vendors may have need for symmetric secrets like these for their own use,
but if we were to extend ACME to allow such “external” secrets, we should standardize their secure use.

For example, a much safer way to embed “external_secret”, “ca-account-secret”, and “token” would be 
to have an “external-key-id” field, that indicates a MAC key that has been exchanged out-of-band;
we would then use MAC-based authentication to bind the MAC key to the relevant JWS request,
using the standard nested authentication mechanism we are using in roll-over, something like:
	
	Sign (account-key, (request, external-key-id, MAC (external_key, Hash(account_key))))

This would ensure that the external secret is never sent on the wire and is not a bearer token,
and the compound authentication guarantees of the resulting protocol are quite strong.

More generally, ACME is not a browser-based protocol and there is no need for us to rely
on obsolete cookie-like mechanisms; ACME clients and servers are already doing crypto,
so why not use MACs instead of passing bearer tokens in URLs or in the request?

Best,
Karthik

> On 31 Oct 2016, at 16:43, Ray Cheng <[email-masked]> wrote:
> 
> Hi Jacob,
>

---

From: Richard Barnes <[email-masked]>
Date: Sun, 20 Nov 2016 08:44:37 -0500

This is a good point.  ACME clients are not limited to dumb pass-through;
they can do intelligent things with the things users give them.  If this is
something CAs can live with, I can update the PR to implement it.

It seems like there are a few implications of this in practice:

1. The CA has to generate / store two random values instead of one
2. The client has to convert a user-input value to a MAC key
3. Both sides have to implement a MAC construction

Of these, the one that worries me most is (2).  The user interface is going
to be string-oriented, so the server and the client have to agree on the
mapping between MAC keys and strings.  So while configuration formats are
usually out of the scope of protocol specs, we should probably specify a
format here.  Among the obvious options (1) hex, (2) base64url, and (3)
UTF-8, my preference order would probably be 1 = 2 > 3.

As far as the MAC, I would probably just have an inner, MAC-based JWS, as
for key roll-over, using the "kid" field for the key ID:

{
  "protected": base64url({
    "alg": "ES256",
    "jwk": /* account key */,
    "nonce": "K60BWPrMQG9SDxBDS_xtSw",
    "url": "https://example.com/acme/new-acct"
  }),
  "payload": base64url({
    "contact": ["mailto:[email-masked]"],
    "terms-of-service-agreed": true,

    "external-account-binding": {
      "protected": base64url({
        "alg": "HS256",
        "kid": /* key identifier */,
      }),
      "payload": base64url({
        "accountKey": /* same as in "jwk" above */
      }),
      "signature": "Xe8B94RD30Azj2ea...8BmZIRtcSKPSd8gU"
    }
  }),
  "signature": "5TWiqIYQfIDfALQv...x9C2mg8JGPxl5bI4"
}

This will be a fair bit more spec text, and a little more code, but it
seems worth it.

--Richard

On Sat, Nov 19, 2016 at 2:22 AM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> For example, a much safer way to embed “external_secret”,
> “ca-account-secret”, and “token” would be
> > We are effectively using "ca-account-id" and "ca-account-secret" fields
> to authenticate the link to the Entrust account. Since these fields do not

---

From: Ray Cheng <[email-masked]>
Date: Mon, 21 Nov 2016 19:52:10 +0000

Hi Richard,

Yes, the registries of field names would address our needs.

Can you clarify what you mean by:  "… the only requirement to add something to the registry is that there be a specification for it somewhere"?
What does "somewhere" refer to in this context?

Ray

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, November 18, 2016 8:09 PM
To: Ray Cheng <[email-masked]>
Cc: [email-masked]; Jacob Hoffman-Andrews <[email-masked]>
Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

Hey Ray,
We discussed this at the F2F meeting at IETF 97 last week.  The conclusion there was that we're not going to create a special zone for CA extensions, but rather just let CAs extend the relevant object directly.
The major risk here is collision -- if two CAs extend an object using the same field name with different semantics.  To help avoid that, I've posted a PR that creates registries of field names; the only requirement to add something to the registry is that there be a specification for it somewhere.

On Tue, Nov 1, 2016 at 12:43 AM, Ray Cheng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jacob,

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Nov 2016 15:22:00 -0500

On Mon, Nov 21, 2016 at 2:52 PM, Ray Cheng <[email-masked]>
wrote:

> Can you clarify what you mean by:  "… the only requirement to add
> something to the registry is that there be a specification for it
> somewhere"?
>

The current PR defines the registries as "specification required", as
defined here:

https://tools.ietf.org/html/rfc5226#section-4.1

"""
Values and their meanings must be
documented in a permanent and readily available public
specification, in sufficient detail so that interoperability
between independent implementations is possible.
"""

>
>
> Ray
>
>
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, November 18, 2016 8:09 PM
> *To:* Ray Cheng <[email-masked]>
> *Cc:* [email-masked]; Jacob Hoffman-Andrews <[email-masked]>
> *Subject:* Re: [Acme] Proposal for adding arbitrary CA-specific
> name-value pairs to registration object
>
>
>
> Hey Ray,
>

---

From: Ray Cheng <[email-masked]>
Date: Tue, 22 Nov 2016 18:33:08 +0000

We are using a "ca-account-secret" with the "new-reg" request to make an association between the ACME account key and a CA account. 

We have implemented additional security measures around our “ca-account-secret” beyond ACME to satisfy our own security requirements, for example:
1. Secret expiry 
2. Account lockout
3. Human approval post association
4. Monitoring

At least for our CA use case, the logistics of having to distribute a MAC key out of band would make it impractical enough that we would likely choose other options. For example, we could just have someone manually provision their ACME account public key into our CA account system to make the association. We didn't choose this route as it was deemed less operator-friendly.

Regards,

Ray

> -----Original Message-----
> From: Karthikeyan Bhargavan [mailto:[email-masked]]
> Sent: Saturday, November 19, 2016 2:23 AM
> It is worth noting that “external_secret”, “ca-account-secret”, and
> “token” are all secret bearer tokens and, as such, offer *significantly*
> less security than the default ACME mechanisms, and in some cases may
> defeat the purpose of having account keys.
> 
> I can see that different vendors may have need for symmetric secrets like
> these for their own use, but if we were to extend ACME to allow such
> “external” secrets, we should standardize their secure use.
> 
> For example, a much safer way to embed “external_secret”, “ca-account-
> secret”, and “token” would be to have an “external-key-id” field, that
> indicates a MAC key that has been exchanged out-of-band; we would then use
> MAC-based authentication to bind the MAC key to the relevant JWS request,
> This would ensure that the external secret is never sent on the wire and
> is not a bearer token, and the compound authentication guarantees of the
> resulting protocol are quite strong.
> 
> More generally, ACME is not a browser-based protocol and there is no need
> for us to rely on obsolete cookie-like mechanisms; ACME clients and
> servers are already doing crypto, so why not use MACs instead of passing
> bearer tokens in URLs or in the request?
> 
> Best,
> Karthik
> 
> >> places we've intentional left hooks for CA-specific customization,
> >> like OOB challenges. I'm inclined to accept it.
> >>
> >> Additionally, your experience as a commercial implementer of ACME may
> >> be valuable to spot places where the current protocol is lacking. For
> >> (https://github.com/ietf-wg-acme/acme/pull/172) a "token" field. Can
> >> we support those use cases natively in ACME so they don't need to be
> explicit fields in ACME. There are some advantages to explicit fields -
> one in particular is the special handling of designated secret fields by
> clients.
> >

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Nov 2016 15:37:08 -0500

On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng <[email-masked]>
wrote:

> We are using a "ca-account-secret" with the "new-reg" request to make an
> association between the ACME account key and a CA account.
>
> We have implemented additional security measures around our
> “ca-account-secret” beyond ACME to satisfy our own security requirements,
> for example:
> 1. Secret expiry
> 2. Account lockout
> At least for our CA use case, the logistics of having to distribute a MAC
> key out of band would make it impractical enough that we would likely
> choose other options. For example, we could just have someone manually
> provision their ACME account public key into our CA account system to make
> the association. We didn't choose this route as it was deemed less
> operator-friendly.
>

I'm a little confused here.  The only thing that "distributing a MAC key
out of band" requires is that you give the customer two strings instead of
one.  Assuming client software had a place to copy/paste in each of these,
could you work with that?

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Nov 2016 16:54:49 -0500

> could you work with that?

Here's a PR implementing this idea, for concreteness:

https://github.com/ietf-wg-acme/acme/pull/212

---

From: Clint Wilson <[email-masked]>
Date: Wed, 23 Nov 2016 00:43:14 +0000

This is great! We can use this in a very similar way to just passing back
to the client an "external_secret" value, but it adds a substantial amount
of authentication to the binding. Given that strong authentication is the
goal in adding this object, I'm in favor of the proposed implementation of
the external-account-binding object.

Cheers!
-Clint

---

From: Ray Cheng <[email-masked]>
Date: Wed, 23 Nov 2016 01:57:05 +0000

Richard and Karthikeyan,

We had to support not making copy/paste a hard requirement – desirable perhaps but not mandatory.
Our "ca-account-secret" put us in the copy/paste desirable space, but still do-able without it.  A MAC key is realistically  in the do-able only with copy/paste spectrum.

If you assume copy/paste is available, then the usability impact of introducing a MAC key is lessened as Richard has described.
This is a  reasonable assumption in most cases so https://github.com/ietf-wg-acme/acme/pull/212 is a good step forward for these more general use cases.

I believe we still have the option of using  https://github.com/ietf-wg-acme/acme/pull/211 to register custom fields for use cases not covered by https://github.com/ietf-wg-acme/acme/pull/212. These two PRs together should  give us the security and flexibility that we need.

Ray

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, November 22, 2016 4:55 PM
To: Ray Cheng <[email-masked]>
Cc: Karthikeyan Bhargavan <[email-masked]>; [email-masked]; Jacob Hoffman-Andrews <[email-masked]>
Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

On Tue, Nov 22, 2016 at 3:37 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng <[email-masked]<mailto:[email-masked]>> wrote:
We are using a "ca-account-secret" with the "new-reg" request to make an association between the ACME account key and a CA account.

I'm a little confused here.  The only thing that "distributing a MAC key out of band" requires is that you give the customer two strings instead of one.  Assuming client software had a place to copy/paste in each of these, could you work with that?

--Richard

Regards,

Ray

> From: Karthikeyan Bhargavan [mailto:[email-masked]<mailto:[email-masked]>]
> To: Ray Cheng <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Jacob Hoffman-Andrews <[email-masked]<mailto:[email-masked]>>
> > On 31 Oct 2016, at 16:43, Ray Cheng <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hi Jacob,
> >

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 23 Nov 2016 07:59:09 +0100

Thanks for the clarification, Ray.

I am guessing not having copy/paste means that the customer should be able to type in the token into the ACME client?

If so, a second (less desirable, but still) option for non-copy-paste scenarios would be to generate a MAC key from the token,
using a strong modern PBKDF. ACME clients would not normally implement this primitive, because they have no need for it,
so you’d either need to extend the ACME client or ask customers to use a command-line key derivation function.

I think everyone gets this, but just to be clear… There may well be some use cases where bearer tokens are the right light-weight solution.  
The main concern is about high-value secret tokens, where knowing a token would allow an attacker to take over an account
(and/or link a CA website account to the attacker’s account key). The ACME threat model explicitly states that the network
connection between the ACME client and server should not be relied on for confidentiality (e.g. the server may be hosted by a CDN)
and this isn’t compatible with a secret bearer token.

> On 23 Nov 2016, at 02:57, Ray Cheng <[email-masked]> wrote:
> 
> Richard and Karthikeyan,
>  
> This is a  reasonable assumption in most cases so https://github.com/ietf-wg-acme/acme/pull/212 <https://github.com/ietf-wg-acme/acme/pull/212> is a good step forward for these more general use cases.
>  
> I believe we still have the option of using  https://github.com/ietf-wg-acme/acme/pull/211 <https://github.com/ietf-wg-acme/acme/pull/211> to register custom fields for use cases not covered by https://github.com/ietf-wg-acme/acme/pull/212 <https://github.com/ietf-wg-acme/acme/pull/212>. These two PRs together should  give us the security and flexibility that we need.
>  
> Ray
>  
>  
> On Tue, Nov 22, 2016 at 3:37 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng <[email-masked] <mailto:[email-masked]>> wrote:
> https://github.com/ietf-wg-acme/acme/pull/212 <https://github.com/ietf-wg-acme/acme/pull/212>
> 
>  
>  
> --Richard
> 
> 
>  
> 
> Regards,
> 
> Ray
> 
> > From: Karthikeyan Bhargavan [mailto:[email-masked] <mailto:[email-masked]>]
> > To: Ray Cheng <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>; Jacob Hoffman-Andrews <[email-masked] <mailto:[email-masked]>>
> > > On 31 Oct 2016, at 16:43, Ray Cheng <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > >
> > > Hi Jacob,
> > >
> > >> (https://github.com/ietf-wg-acme/acme/pull/172 <https://github.com/ietf-wg-acme/acme/pull/172>) a "token" field. Can
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 23 Nov 2016 09:28:34 -0500

I would also note that a lack of copy-and-paste need not necessarily be a
barrier to sending around MAC keys.

First (and Karthik may punch me in the face for saying this) but I think
even with a short (say 8-character) MAC key, you're better off than having
a bearer token.

Second, you can make base64url-encoded strings that have non-trivial
entropy and are still easy to type.  For instance,
"lorem-ipsum-dolor-sit-amet" is a valid base64url string (corresponding to
"968ade9be8a9b2e9be768968afeb22b7e6a67a" in hex).  That wouldn't get you
the full entropy for the length of the string, but with sufficiently-large
word list, you could get up to ~64 bits.

On Wed, Nov 23, 2016 at 1:59 AM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> I am guessing not having copy/paste means that the customer should be able
> to type in the token into the ACME client?
>
> If so, a second (less desirable, but still) option for non-copy-paste
> scenarios would be to generate a MAC key from the token,
> using a strong modern PBKDF. ACME clients would not normally implement
> this primitive, because they have no need for it,
> I think everyone gets this, but just to be clear… There may well be some
> use cases where bearer tokens are the right light-weight solution.
> The main concern is about high-value secret tokens, where knowing a token
> would allow an attacker to take over an account
> (and/or link a CA website account to the attacker’s account key). The ACME
> threat model explicitly states that the network
> connection between the ACME client and server should not be relied on for
> confidentiality (e.g. the server may be hosted by a CDN)
> Our "ca-account-secret" put us in the copy/paste desirable space, but
> still do-able without it.  A MAC key is realistically  in the do-able only
> with copy/paste spectrum.
>
> If you assume copy/paste is available, then the usability impact of
> introducing a MAC key is lessened as Richard has described.
> This is a  reasonable assumption in most cases so
> https://github.com/ietf-wg-acme/acme/pull/212 is a good step forward for
> these more general use cases.
>
> I believe we still have the option of using  https://github.com/ietf-wg-
> acme/acme/pull/211 to register custom fields for use cases not covered by
> https://github.com/ietf-wg-acme/acme/pull/212. These two PRs together
> should  give us the security and flexibility that we need.
>
> Ray
>
>
> *From:* Richard Barnes [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, November 22, 2016 4:55 PM
> *Cc:* Karthikeyan Bhargavan <[email-masked]>; [email-masked];
> Jacob Hoffman-Andrews <[email-masked]>

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 23 Nov 2016 15:36:42 -0500

Before we go too far down the road experimenting with short MAC keys and
PBKDF functions I would appreciate if Entrust could elaborate on the
copy/paste hesitation. Why was it not possible to make this a hard
requirement?

Taking a further step back, I'm not certain I understand why the
"ca-account-secret" is less of a usability burden than the proposed MAC key
usage. Is the "ca-account-secret" a human memorable secret (e.g.
password...) in your existing system?

On Wed, Nov 23, 2016 at 9:28 AM, Richard Barnes <[email-masked]> wrote:

> "lorem-ipsum-dolor-sit-amet" is a valid base64url string (corresponding to "
> 968ade9be8a9b2e9be768968afeb22b7e6a67a" in hex).  That wouldn't get you
>> I am guessing not having copy/paste means that the customer should be
>> able to type in the token into the ACME client?
>>
>> (and/or link a CA website account to the attacker’s account key). The
>> ACME threat model explicitly states that the network
>> I believe we still have the option of using
>> https://github.com/ietf-wg-acme/acme/pull/211 to register custom fields
>> for use cases not covered by https://github.com/ietf-wg-
>> acme/acme/pull/212. These two PRs together should  give us the security
>> and flexibility that we need.
>>
>> Ray
>>
>>

---

From: Ray Cheng <[email-masked]>
Date: Thu, 24 Nov 2016 15:01:55 +0000

Richard/ Karthik,

I would like to emphasize a couple of points that may not have been clear from my last set of comments.

-  You should NOT try to accommodate the our very specific use case in https://github.com/ietf-wg-acme/acme/pull/212. You should continue to pursue the goal of the PR to achieve the strongest external account binding possible. "pull/212" may be an option for us to adopt in the future.

- The biggest difference between "pull/212" and our use of "ca-account-secret" is that we do not use "ca-account-secret" in isolation. We do additional out of band checks before the "final  binding" that are very CA specific. I expect that these very CA-specific out of band checks would be outside the scope of the ACME specification. We simply need a place in the protocol where we can pass "ca-account-secret" type of info so we can integrate it with our additional out-of-band process. I believe https://github.com/ietf-wg-acme/acme/pull/211 will achieve this for us.

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, November 23, 2016 9:29 AM
To: Karthikeyan Bhargavan <[email-masked]>
Cc: Ray Cheng <[email-masked]>; [email-masked]; Jacob Hoffman-Andrews <[email-masked]>
Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value pairs to registration object

I would also note that a lack of copy-and-paste need not necessarily be a barrier to sending around MAC keys.

First (and Karthik may punch me in the face for saying this) but I think even with a short (say 8-character) MAC key, you're better off than having a bearer token.

Second, you can make base64url-encoded strings that have non-trivial entropy and are still easy to type.  For instance, "lorem-ipsum-dolor-sit-amet" is a valid base64url string (corresponding to "968ade9be8a9b2e9be768968afeb22b7e6a67a" in hex).  That wouldn't get you the full entropy for the length of the string, but with sufficiently-large word list, you could get up to ~64 bits.

On Wed, Nov 23, 2016 at 1:59 AM, Karthikeyan Bhargavan <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the clarification, Ray.

On 23 Nov 2016, at 02:57, Ray Cheng <[email-masked]<mailto:[email-masked]>> wrote:

Richard and Karthikeyan,

Ray

Cc: Karthikeyan Bhargavan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jacob Hoffman-Andrews <[email-masked]<mailto:[email-masked]>>

--Richard

Regards,

Ray