Hi Hannes, I have submitted a new version of the draft which I believe addresses your concerns. Here is a diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03
While Alan and Jouni have already provided excellent answers to most of your comments, in-line you can find a few more clarifications for the changes I made. --Mohit On 3/24/20 10:00 AM, Hannes Tschofenig wrote: > Hi Michael, Hi draft authors, > >> I was surprised to get to the end of the document without any suggestions >> about sending certificates by reference rather than value. > Having seen this statement from Michael I have reviewed the document. Two > generic observations about the draft: > > 1) Many statements are made about deployments and no references are provided. > To improve quality of the write-up I would strongly suggest to add such > references, as you would have to do with an academic publication as well. > > 2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached > Info was wrongly interpreted. They actually relate to the remark from > Michael. > >> TLS certificates are often relatively large, and the certificate >> chains are often long. > I think this statement is in general incorrect. You could say that in > deployment X certificates have size X and the chain is Y long. > > >> Also, >> from deployment experience, EAP peers typically have longer >> certificate chains than servers. > I would like a reference to be included here. Theoretically, it makes no > sense to > have a certificate chain for an EAP peer to have a longer certificate chain > than a server > given a EAP peer talks to one EAP server. > > In network access authentication it is not only about authentication but the > most important part is authorization. Hence, you pretty much always have a > one-to-one relationship between the EAP peer and the EAP server. There are no > good reasons to have complex CA hierarchies here. > >> This is because EAP peers often >> follow organizational hierarchies and tend to have many intermediate >> certificates. Thus, EAP-TLS authentication usually involve >> significantly more octets than when TLS is used as part of HTTPS. > I think it would make sense to explain this organizational hierarchy aspect > in a bit > more detail. > >> The EAP fragment size >> in typical deployments is just 1020 - 1500 octets. > Reference for the 1500 octets. Added that this limitation come from Ethernet II frame size. > > >> For example, many EAP authenticator (access point) >> implementations will drop an EAP session if it has not finished after >> 40 - 50 round-trips. > Is there a reference that could be included? > >> However, deployment >> experience has shown that these jumbo frames are not always >> implemented correctly. > Add a reference here. > >> RADIUS can generally transport only about 4000 >> octets of EAP in a single message. > How was this number constructed? Added that RADIUS RFC2865 limits length to 4096 octets. > >> A certificate chain (called a certification path in [RFC5280]) can >> have 2 - 6 intermediate certificates between the end-entity >> certificate and the trust anchor [RFC5280]. > The PKIX reference here is misleading. I think you included it to refer to > the terms but it sounds like the statement that > the chain can have 2-6 intermediate CA certificates. > > I would add the terms to the terminology section and remove the PKIX > reference here. Done. Thanks. Indeed that was misleading. > > I am also wondering what you are trying to say here with this sentence. Are > you saying that you have seen deployments > for network access authentication that have up to 6 intermediate CA > certificates in the chain? > > >> 3. Experience with Deployments >> Most common access point implementations drop EAP sessions that do >> not complete within 50 round-trips. > This sentence is a repetition. > >> This means that if the chain is >> larger than ~ 60 kB, EAP-TLS authentication cannot complete >> successfully in most deployments. > Regarding the 60 kB certificate chain: Should this be an indication to > someone deploying > the technology for access network authentication that something has gone > wrong? > > Is this someone you have observed or is this just a theoretical statement? I > hope it is the latter. > > > 4.2.1. Pre-distributing and Omitting CA Certificates > > >> When using TLS 1.3, all certificates that >> specify a trust anchor known by the other endpoint may be omitted >> (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, >> only the self-signed certificate that specifies the root certificate >> authority may be omitted (see Section 7.4.2 of [RFC5246] > These sentences sound strange. > > In TLS (and probably other protocols) it makes no sense to distribute the > trust anchors in the protocol itself (because then they wouldn't serve as an > anchor for trust). > > It is my understanding that the TLS 1.3 spec does not require you > to send intermediate CA certificates if they have been provisioned to the peer > out-of-band already. The text in the TLS 1.2 spec is a bit fuzzy and calls > out that the > self-signed root certificate MAY be omitted but it does not say anything > about omitting > the other certs. RFC8446 says in Section 4.4.2 "a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.". We write "all certificates that specify a trust anchor known by the other endpoint may be omitted". Please let us know if you have suggestions for improving the text. > >> 4.2.2. Caching Certificates > There seems to be the misconception that TLS Cached Info requires a full > exchange to work. > It is the other way around: If you pre-distribute certificates upfront then > there is no need > to exchange the certs again. You could just send the fingerprints right away. > > A spec, however, has to also cover the bootstrapping problem. Where does RFC 7924 say this? The text in the RFC clearly states that: "This specification defines a TLS extension that allows a client and a server to exclude transmission information cached in an earlier TLS handshake.". Notice the "earlier TLS handshake" part. We discussed at IETF 102 whether we allow caching of validated certificate chain even if EAP-TLS authentication fails. See slide 5: https://datatracker.ietf.org/meeting/102/materials/slides-102-emu-large-certificates-in-eap-tls-00. The consensus was not to do that. > >> 4.2.5. Using Fewer Intermediate Certificates >> The EAP peer certificate chain does not have to mirror the >> organizational hierarchy. For successful EAP-TLS authentication, >> certificate chains should not contain more than 2-4 intermediate >> certificates. > I would make a stronger statement here. There is absolutely no reason for the > certificate > chain to mirror the organizational structure. > > I also don't understand why you would need a hierarchy of 4 intermediate CAs. > > Finally, at the end: Why did you omit > - Client Certificate URLs - RFC 6066), which is also referenced in RFC 7925 > and > - cTLS (which also has a certificate compression scheme included). Added a section on both. While I was aware of the cTLS work, I had completely missed RFC6066. Reviews from experienced people like you ensure that we don't miss important existing work. > > Theoretically, you could even list the ability to use alternative certificate > format here. Then, you could list raw public keys or the CWT extension. I think tit is better to leave these for a separate document. > > Ciao > Hannes > > PS: It is good to see John's name on a document that talks about TLS. He is also an author of EAP-TLS13 and EAP-TLS-PSK. I certainly hope that the battles for a lightweight authenticated key exchange (lake) stay there and don't affect the work of other groups. --Mohit > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
