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:r...@ipv.sx] Sent: Tuesday, November 22, 2016 4:55 PM To: Ray Cheng <ray.ch...@entrustdatacard.com> Cc: Karthikeyan Bhargavan <karthik.bharga...@gmail.com>; acme@ietf.org; Jacob Hoffman-Andrews <j...@eff.org> 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 <r...@ipv.sx<mailto:r...@ipv.sx>> wrote: On Tue, Nov 22, 2016 at 1:33 PM, Ray Cheng <ray.ch...@entrustdatacard.com<mailto:ray.ch...@entrustdatacard.com>> 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:karthik.bharga...@gmail.com<mailto:karthik.bharga...@gmail.com>] > Sent: Saturday, November 19, 2016 2:23 AM > To: Ray Cheng > <ray.ch...@entrustdatacard.com<mailto:ray.ch...@entrustdatacard.com>> > Cc: acme@ietf.org<mailto:acme@ietf.org>; Jacob Hoffman-Andrews > <j...@eff.org<mailto:j...@eff.org>> > 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 > > <ray.ch...@entrustdatacard.com<mailto:ray.ch...@entrustdatacard.com>> > 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 > > Acme@ietf.org<mailto:Acme@ietf.org> > > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
