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 protected]> wrote: > 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 protected]> wrote: > > 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 protected] <[email protected]>] > *Sent:* Tuesday, November 22, 2016 4:55 PM > *To:* Ray Cheng <[email protected]> > *Cc:* Karthikeyan Bhargavan <[email protected]>; [email protected]; > Jacob Hoffman-Andrews <[email protected]> > *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 protected]> wrote: > > On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng <[email protected]> > 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 > 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. > > > 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? > > > Here's a PR implementing this idea, for concreteness: > > https://github.com/ietf-wg-acme/acme/pull/212 > > > > > --Richard > > > > > > Regards, > > Ray > > > -----Original Message----- > > From: Karthikeyan Bhargavan [mailto:[email protected]] > > Sent: Saturday, November 19, 2016 2:23 AM > > To: Ray Cheng <[email protected]> > > Cc: [email protected]; Jacob Hoffman-Andrews <[email protected]> > > Subject: Re: [Acme] Proposal for adding arbitrary CA-specific name-value > > pairs to registration object > > > > 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 protected]> > > wrote: > > > > > > 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. > > > > > > > > > _______________________________________________ > > > Acme mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
