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? --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
