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
