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 protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
