upros/acme-integrations

ACME Integrations

This is the working area for the individual Internet-Draft, "ACME Integrations".

• Editor's Copy
• Individual Draft
• Compare Editor's Copy to Individual Draft

Building the Draft

Formatted text and HTML versions of the draft can be built using make.

$ make

This requires that you have the necessary software installed. See the instructions.

Contributing

See the guidelines for contributions.

acme-integrations's Issues

Change to DNS terminology

From mailer feedback:

Section 2: I like the DNS terminology (I can’t say if they are correct). For me, they are clear and easy to understand.

AD Review Section 2

** Section 2. Editorial. The definition of subdomain uses explicit quotes around text from RFC1034. However, label comes verbatim of RFC8499, why not quotes around it?

AD Review Section 5

** Section 5.

In the example
illustrated here, the extension to [RFC8366] Vouchers which is
defined in [I-D.ietf-anima-brski-cloud],

-- Editorially, that [RFC8366] doesn't work. Should it be after "Vouchers"?

-- I'm not following the RFC8366 link. The data flow seems consistent with Section 4.2 of [I-D.ietf-anima-brski-cloud]

Russ #11

Section 7.4: s/id-kp-cmcRA extended key usage bit/id-kp-cmcRA extended key usage OID/ (multiple places)

AD Review Section 9.1

** Section 9.1

As many ACME servers have per-day, per-IP and per-subjectAltName
limits, it is prudent not to request identical certificates too
often. This could be due to operator or installer error, with
multiple configuration resets occurring within a short period of
time.

-- Is this commenting on the operational practices of current, public ACME servers? Would this apply (assuming they are used) private servers? Servers an organization has a contractual/provisioned/SLA-based relationship?

-- If requests are spaced out, isn't the value of the using the efficiency of the sub-domain technique less relevant?

Russ #2

Section 1, last para: Please reword. Something like:

Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
useful optimization when ACME is used to issue certificates for large
numbers of devices; it reduces the domain ownership proof traffic as
well as the ACME traffic overhead. This is accomplished by completing
a challenge against the parent domain instead of a challenge against
each explicit subdomain. Use of ACME for subdomains is not a
necessary requirement.

Russ #5

Section 2: Please add a reference for TLV. Consider [RFC7170].

Russ #3

Section 2: Please add a reference for CSR. Consider [RFC2986].

John Levine pre-authorization examples

In the four examples, EAP and TEAP have pre-authorization as the first step, while the two BRSKI ones just say it's complete. It's not clear whether there's something different about BRKSI pre-auth. If there is, it would be nice to note why, if not, perhaps the TEAP one could take it out and say the first step is complete as the BRSKI ones do. Other than that, the diagrams are quite clear even though they are long.

Ted Lemon Security Considerations: DNS RFC3007 specifics

It is expected that the TEAP-EAP server/EST Registrar will perform DNS
dynamic updates to a DNS primary server using [RFC3007] Dynamic updates, secured with either SIG(0), or TSIG keys.

This seems needlessly prescriptive. I think it's quite reasonable to think that an implementation might use some mechanism for directly writing to the primary zone database rather than using either type of DNS update. You are describing a vulnerability related to updates of this type, so maybe you should just say "in the case that the TEAP-EAP server/EST registrar performs DNS dynamic updates ..."

Joe Salowey tls-unique binding

I have one question, bot EST and TEAP allow the option for the client to bind the PKCS#10 message to the TLS tunnel by inserting the TLS unique into the message challenge password field. The draft makes no mention of this facility, should it? I we expect that the default expectation would be this would be included unless there was a reason not to.

John Levine error handling ambiguity

In each of the four examples, I gather that the servers are already configured to handle subdomains of example.com, per the second para of
7.5 that says it's an error if a client asks for anything else. This is likely obvious if you know about EST, BRKSI, and TEAP, but it would be a kindness to us newbies to note it perhaps just before section 3.

AD Review Section 6 #3

** Section 6. Diagram

Step 2 is "Establish Outer Tunnel". Isn't the last step of it the follow (i.e., the client responding back with the Result TLV= Success.

   |  EAP-Response/          |                      |           |
   |   Type=TEAP,            |                      |           |
   |   {Crypto-Binding TLV,  |                      |           |
   |   Result TLV=Success}   |                      |           |
   |------------------------>|                      

However, the following is being shown as the last step:

   |  EAP-Request/           |                      |           |
   |   Type=TEAP,            |                      |           |
   |   {Request-Action TLV:  |                      |           |
   |     Status=Failure,     |                      |           |
   |     Action=Process-TLV, |                      |           |
   |     TLV=CSR-Attributes, |                      |           |
   |     TLV=PKCS#10}        |                      |           |
   |<------------------------|                      

AD Review Section 7.1 #1

** Section 7.1.

It
is expected that the EST RA or TEAP servers that the client sends
certificate enrollment requests to are operated by the organization
that controls the domains.

Is this the same as saying that this integration architecture requires that the EST RA/TEAP server be operated by the organization that controls the domains? The current text seems a ambiguous.

CMS Acronym

From mailer feedback:

Section 2: CMS – spell this out the first time.

Russ #8

Section 7.2: s/The identifier must/The identifier MUST/

Ted Lemon Terminology

In section 2, Terminology:

Using graph theory, a label identifies one node in a portion of the
graph of
all possible domain names.

This statement is immediately followed by this:

Domain Name: An ordered list of one or more labels.

Subdomain ...

I assume that the point you're getting at here is that labels are nodes in a tree, when talking in terms of the domain naming hierarchy, and nodes in an ordered list, in the case of a domain name, and "directed graph" is the direct superset of these two things. So I get why this more general term was used, but I don't think it's going to clarify anything for the reader. If you want the reader to really have a mental model that's oriented around graph theory, you probably need to actually be specific about what each of these things is in relation to graph theory. E.g., maybe say:

• every node in the tree of the domain hierarchy is a label.
• a domain name describes a particular path along that tree between two nodes one of which is below the other in the tree hierachy, where each label is hierarchically below the label to its right (if any) and hierarchically above the label to its left (if any), with each pair of labels separated by a '.'. * an FQDN is a path along the tree between the root node and some other node (all nodes on the tree obviously being hierarchically below the root node), with the root label being represented by a trailing '.'

I'm not seriously proposing that you make this change, but if you don't, I think you should delete the sentence about graph theory, because it's just confusingly broad if you don't then actually describe the subset of graph theory you're talking about.

AD Review Section 6 #1

** Section 6. I don't have the full history on draft-ietf-eap-teap-brski. However, it seems unusual to be effectively specifying an applicability statement for an expired, unadopted draft. Is there significant usage of this draft in the field? What's the motivation?

AD Review Section 7.1 #2

** Section 7.1

If the client sends a certificate enrollment request for an
identifier in a domain that the EST RA or TEAP server does not have
operational control over, the server SHOULD reject the request with a
suitable error immediately, and not send a certificate enrollment
request to the ACME server.

What is the circumstance where the server would honor the request for a domain it doesn't control (i.e., why not "server MUST reject")?

Russ #9

Section 7.3: s/certificate MAY be omitted from the chain/certificate SHOULD be omitted from the chain/

AD Review Section 6 #2

** Section 6. Typo. s/STEP 2: Establsh/STEP 2: Establish/

AD Review Section 7.5 #1

** Section 7.5.

If a client sends a certificate enrollment request to an EST RA for
an identifier that the RA does not control, the RA SHOULD respond
with a suitable 4xx HTTP [RFC9110] error code, and SHOULD NOT send an
enrollment request to the ACME server.

-- This guidance appears to weaken the guidance given in Section 4.2.3 of RFC7030:

The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
error code when a problem occurs.

-- Under what circumstance would the RA send a request to the ACME server for an identity it doesn't control? Why isn't this behavior strictly forbidden?

Carl #1

I’ll reply here to add one comment. The introduction of the potential for errors due to domains the RA is authorized for and those may be requested is not called out to any extent. It is likely something that is mostly addressed by authentication to the RA and could be noted as such in section 7.1. Section 7.5 gets at the issue with the mapping for badIdentity, but it could be called out as something that occurs upon submission of request to the RA (vs mapping an ACME error back to the protocol of interest after failed interaction with the ACME server).

AD Review Section 1

** Section 1. Editorial clarity.
OLD
Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a
useful optimization when ACME is used to issue certificates for large
numbers of devices;

NEW
Optionally, ACME for subdomains [I-D.ietf-acme-subdomains] offers a useful optimization when ACME is used to issue certificates for large numbers of devices in the same domain;

AD Review Section 4

** Section 4. Editorial. Consider introducing the MASA somewhere in the narrative text prior to the figure as this is a new entity in the typical ACME flows.

AD Review Section 3 - 6

** Section 3 - 6. All of the reference flows appear to use dns-01 challenge types. Are others possible? Even if not, please explicitly say that this challenge type is being used.

Bo Wu draft title

It would be clearer if the draft title matchs the content,e.g. ACME integration for device certificate enrollment.

Bo Wu nits

1. In Section 6, s/enrol/enroll
   After establishing the outer TLS tunnel, the TEAP server instructs the client to enrol for a certificate by sending a PKCS#10 TLV in the body of a Request-Action TLV.

2. In Section 9, s/the the/the
   An attacker that has access to them, can provision their own certificates into the the name space of the entity.

AD Review Section 7.5 #3

** Section 7.5. Typo. Wrong case.
-- s/section 6.7/Section 6.7/
-- s/section 4.2.3/Section 4.2.3/
-- s/section 4.2.6/Section 4.2.6/

MASA Terminology

From mailer feedback:

Section 4, para 1: Spell out MASA somewhere. Maybe in the terms in Section 2. I know MASA is defined in BRSKI, but this would at least give the reader a hint.

Russ #4

Section 2: Please add a reference for RA. Consider [RFC5280].

write security considerations

1. important for intermediate systems (the integrating ones), to be aware of rate limits.

   • caching the CSR, and responding with the same certificate, for the same CSR helps.
   • until certificate expiry date.

2. always reuse CSR on client, unless there is a reason to change it.

Russ #6

Section 4: Please fix the markdown typo: Refer to section {csr-attributes} for more details.

what happens when there is a failure?

does the ACME failure get communicated to the pledge somehow?

Russ #7

Section 7.2 says:

EST [RFC7030] is not clear on how the CSR Attributes response should
be structured, and in particular is not clear on how a server can
instruct a client to include specific attribute values in its CSR.
[I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
use CSR Attributes response to specify specific values for attributes
that the client should include in its CSR.

Servers MUST use this mechanism to tell the client what identifiers
to include in CSR request. ...

This is a MUST, but is is not really nailed down. Can we get to a simple MUST statement here? If not, can we at least narrow the possibilities?

Russ #1

Section 1, para 1: Please add a cite to [RFC5280] after "X.509 (PKIX) certificate".

AD Review Section 10

** Section 10. There are no normative references in this document despite RFC2119-style language being made about compliance to those documents. I appreciate that this is an informational document, but it still needs normative references to the specs it is building upon. See https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/.

Please do a more deliberate sweep, but minimally, the following need to be normative: [I-D.ietf-acme-subdomains], [I-D.ietf-anima-brski-cloud], [I-D.ietf-lamps-rfc7030-csrattrs], [I-D.ietf-uta-use-san], [I-D.lear-eap-teap-brski], [RFC2119], [RFC8555], [RFC8995], [RFC7170], [RFC7030], [RFC9110], [RFC8174].

Russ #10

Section 7.3.2: Please provide references for PKCS#7 and PKCS#10.

ACME protocol vs. CA terminology

From mailer feedback:

Section 3: This might be picky, but sometimes it is difficult to distinguish between ACME the protocol and ACME the CA. For example, the call flow chart has a node ‘ACME’, this is the CA, correct? If you wanted to clarify this, I think it would be as easy to change the node to ‘ACME CA’. Again, I will freely admit this might be picky…

Ted Lemon subdomains clarification

In the introduction you say "Use of ACME for subdomains is not a necessary requirement." You should probably delete "necessary" here, but the main reason I call this out is that later on when you are describing ACME integration with TEAP, you only describe it for the subdomain case. Which leads me to the question "which is it?" I.e., are subdomains required for TEAP, and if not, how does it work when you aren't doing subdomains?

AD Review Section 7.5 #2

** Section 7.5. Similar line of questions for TEAP as with EST.

If a client sends a certificate enrollment request to a TEAP server
for an identifier that the TEAP server does not control, the TEAP
server SHOULD respond with an Error TLV with error code 1024 Bad
Identity In Certificate Signing Request, and SHOULD NOT send an
enrollment request to the ACME server.

-- Is this behavior suggesting that TEAP server could silently ignore requests by returning no error? Can the circumstance behind that design choice be explained?

-- As above. Why propagate a bad required to the ACME server?

Ted Lemon Security Considerations TSIG and SIG details

A major source of vulnerability is the disclosure of these DNS key records.
An attacker that has access to them, can provision their own certificates into the the name space of the entity.

This is somewhat inaccurate. TSIG doesn't have KEY records, so you aren't pointing to a thing here if you're using TSIG. In the case of SIG(0), the actual vulbnerability is that the attacker somehow gets the secret key, not the public key. Only the public key appears in a KEY record. So you should probably fix this to more accurately describe the data elements that can be compromised to effect the attack.

Later text made me wonder whether the vulnerability you were talking about here is not that the attacker is able to get at the secret key, but rather that the attacker is able to write its own key, and then use that key to publish the DNS TXT record that's being used for the ACME challenge. If that's the case, this section should probably be clarified to talk about this more specifically.

Ted Lemon ACME spec prior knowledge DNS clarification

As a naive reader of this document, the diagrams that show the ACME process aren't really contextualized as being part of ACME, so when I was reviewing the document, I found myself hunting for where the DNS operations shown in the diagrams are actually described in an RFC. I knew it was part of ACME, but wasn't sure that there weren't additional bits in e.g. the EST or BRSKI specification. It might be helpful to explicitly say that the flow here is defined in the ACME spec. Again, this really depends on who your reader is and how much you want to coddle them, but I thought it was worth mentioning.

TEAP Clarifications

From mailer feedback:

Section 6:
TLV? (This means tag length value, but clearly that is wrong).
I know nothing about TEAP, but does the server initiate normally? (I’m used to seeing client-initiated exchanges)
And this is not for this document, per se, but does TEAP use TLS1.2 (it doesn’t look like TLS 1.3 – change cipher spec, for example)?

Ted Lemon missing references

You probably need a reference to RFC2136 and RFC2931 in addition to the reference to RFC3007.

John Levine Security Considerations

In the Security Considerations, it says that it is expected that the registrar wil use RFC 3007 updates to put records into the DNS. In my admittedly limited ACME experience, it's more common to use a local API to talk to whatever is managing the DNS. (I rolled my own API for my own DNS toaster and acme.sh, because I could.) Is it really limited to RFC 3007 updates? If not, you might want to reword it more generally to say it's going to use something to update the DNS, and if the credentials leak, that would be bad.

I agree with the advice to limit the name scope of updates, and if possible the RRTYPEs. My API only lets the ACME client update CAA and TXT records since that's all ACME needs.