Re: [Acme] AD Review of draft-ietf-acme-integrations-10

["Owen Friel (ofriel)" <[e-mail]>]

Thank you Roman for the review and comments.

I created individual github issues for these comments and have committed fixes for most of them and closed the issues:  https://github.com/upros/acme-integrations/issues

There are three outstanding issues and I will comment on these inline below.

Regards,
Owen

-----Original Message-----
From: Acme <[e-mail]> On Behalf Of Roman Danyliw
Sent: Saturday 29 October 2022 03:34
To: [e-mail]
Subject: [Acme] AD Review of draft-ietf-acme-integrations-10


Hi!
I performed an AD review of draft-ietf-acme-integrations-10.  Thanks for this information document to should the broad applicability of ACME.  My feedback is as follows:


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

[ofriel] The quotes or lack of quotes is itself taken directly from the definitions in RFC8499. If you look at RFC8499, the definition of Label is not in quotes; however, the definition of Subdomain starts with a quote as it is pulling in text from RFC1034 into RFC8499. The text in acme-integrations aligns to the character with what is in RFC8499. Does this make sense?


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

[ofriel] We / cisco are actively working on elements of draft-lear-eap-teap-brski, we just didn't get to updating at IETF115. It might make sense to remove the reference for now, but see next comment.

** 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}        |                      |           |
       |<------------------------|                      

[ofriel] The reason this happens is yes, the client has successfully completed TLS handshake, but the server is explicitly instructing the client to do a CSR Attributes followed by a PKCS#10 cert enrol so that the client will enrol to get a cert that will allow it to access. E.g. the client may start the TEAP transaction with an IDevID, or with an about-to-expire LDevID, thus the server is telling it to get a new cert before it will grant access.

This behavoiur is not too clearly specified in RFC7170, but is clearer in draft-lear-eap-teap-brski. We could possibly drop draft-lear-eap-teap-brski reference and add further clarification in this document over and above what is in RFC7170.