Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Hi Hannes, Thanks for the follow up. I have submitted a new version which should address your concerns. Here is a diff for your convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-04 Please see in-line for some details. --Mohit On 6/8/20 3:19 PM, Hannes Tschofenig wrote: > Thanks for the update, Mohit. > > A few minor remarks: > > FROM: > > " > TLS certificates in EAP deployments can be relatively large, and the > certificate chains can be long. > " > > TO: > > " > Certificates in EAP deployments can be relatively large, and the > certificate chains can be long. > " Done! > > Reason: Certificates are large and there is nothing in TLS that contributes > to the size. > > In Section 4 I would state the obvious to the reader: Keep the certificate > size small by not stuffing lots of fields in it and keep the chain short. > A common reason why these certs are long is because developers don't > understand that they do not need to map the organizational hierarchy to a CA > hierarchy. > This is the simplest approach to reduce the size of certificates sent over > the wire. I added a sentence "The general guideline of keeping the certificate size small by not populating fields with excessive information can help avert the problems of failed EAP-TLS authentication.". Your comment on the needless mapping of the organizational hierarchy to the CA hierarchy is already covered in section 4.2.7. > > Regarding 4.2.3. Compact TLS 1.3 > > [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and > reduces the message size of the protocol by removing obsolete > material and using more efficient encoding. This naturally means > that cTLS is not interoperable with previous versions of the TLS > protocol. It also defines a compression profile with which either > side can define dictionary of "known certificates". Thus, cTLS can > provide another mechanism for EAP-TLS deployments to reduce the size > of messages and avoid excessive fragmentation. > > The point for mentioning cTLS was related to the certificate compression. I > would therefore change the paragraph to: > > 4.2.3. Compact TLS 1.3 > > [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and > reduces the message size of the protocol by removing obsolete > material and using more efficient encoding. It also defines a > compression profile with which either side can define dictionary > of "known certificates". I haven't changed the paragraph. I think it is important to let the reader know that cTLS is not interoperable with previous versions TLS. So updating the peer implementation without updating the server implementation would not help. > > I wonder whether you want to mention also > https://tools.ietf.org/html/draft-tschofenig-tls-cwt-01 and > https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00? > Since those are still individual drafts you could point out that those are > work in progress. I was a bit hesitant to add these since they are still in early phases of development. However, I have now added a section titled "New Certificate Types and Compression Algorithms". Hope this is sufficient. > > Ciao > Hannes > > -Original Message- > From: Mohit Sethi M > Sent: Saturday, May 9, 2020 10:49 AM > To: Hannes Tschofenig ; Michael Richardson > ; emu@ietf.org > Subject: Re: [Emu] My review ... was RE: I-D Action: > draft-ietf-emu-eaptlscert-02.txt > > 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 w
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Thanks for the update, Mohit. A few minor remarks: FROM: " TLS certificates in EAP deployments can be relatively large, and the certificate chains can be long. " TO: " Certificates in EAP deployments can be relatively large, and the certificate chains can be long. " Reason: Certificates are large and there is nothing in TLS that contributes to the size. In Section 4 I would state the obvious to the reader: Keep the certificate size small by not stuffing lots of fields in it and keep the chain short. A common reason why these certs are long is because developers don't understand that they do not need to map the organizational hierarchy to a CA hierarchy. This is the simplest approach to reduce the size of certificates sent over the wire. Regarding 4.2.3. Compact TLS 1.3 [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and reduces the message size of the protocol by removing obsolete material and using more efficient encoding. This naturally means that cTLS is not interoperable with previous versions of the TLS protocol. It also defines a compression profile with which either side can define dictionary of "known certificates". Thus, cTLS can provide another mechanism for EAP-TLS deployments to reduce the size of messages and avoid excessive fragmentation. The point for mentioning cTLS was related to the certificate compression. I would therefore change the paragraph to: 4.2.3. Compact TLS 1.3 [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and reduces the message size of the protocol by removing obsolete material and using more efficient encoding. It also defines a compression profile with which either side can define dictionary of "known certificates". I wonder whether you want to mention also https://tools.ietf.org/html/draft-tschofenig-tls-cwt-01 and https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00? Since those are still individual drafts you could point out that those are work in progress. Ciao Hannes -Original Message- From: Mohit Sethi M Sent: Saturday, May 9, 2020 10:49 AM To: Hannes Tschofenig ; Michael Richardson ; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt 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 f
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
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 unders
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Thanks, Jouni. That's a good clarification. -Original Message- From: Jouni Malinen Sent: Saturday, March 28, 2020 9:26 AM To: Alan DeKok Cc: Hannes Tschofenig ; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt On Tue, Mar 24, 2020 at 10:08:06AM -0400, Alan DeKok wrote: > On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig > wrote: > >> 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? > > References to hostap source code. hostapd has a limit in the EAP server role on the number of round trips (and wpa_supplicant in the EAP peer role). However, there is no such limit in the EAP authenticator role, i.e., hostapd as the access point forwarding EAP to an external RADIUS authentication server does not place such a constraint on the exchange. -- Jouni MalinenPGP id EFC895FA 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
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
On Tue, Mar 24, 2020 at 10:08:06AM -0400, Alan DeKok wrote: > On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig > wrote: > >> 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? > > References to hostap source code. hostapd has a limit in the EAP server role on the number of round trips (and wpa_supplicant in the EAP peer role). However, there is no such limit in the EAP authenticator role, i.e., hostapd as the access point forwarding EAP to an external RADIUS authentication server does not place such a constraint on the exchange. -- Jouni MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
On Mar 25, 2020, at 3:30 AM, Hannes Tschofenig wrote: > Thanks a lot for your comments. I guess you understand that I am always a bit > nervous when the results of non-public conversations dictate the problem > space. I have seen it often enough that people have made their measurements > wrong, had wrong configuration, or had simply misunderstood concepts. Sure. My $0.02 here is that even in the absence of quantitative evidence, we know that the recommendations in the document aren't wrong. i.e. there is little need to have a certificate chain 6 layers deep. There is little need to have each certificate be 16K in size. We may not be *exactly* sure why those things happen. But we can make recommendations for what *should* happen. And, explain why certain (guessed) practices are likely to be wrong. > It sounds like we need a "myth-busting" document. Of course, it isn't certain > whether the decision makers will indeed read RFCs but it would be worthwhile > a try. I think this is it, for the most part. > Also it appears that the authors could do something really actionable here, > namely to update the hostap code to update the roundtrip limit. Hostap supports 50 round trips for TLS ACKs, and 100 if it's exchanging data. This seems reasonable. > PS: Why aren't you a co-author on this document? You know more about this > than anyone else. I'm one of the few willing to *talk* about it. Most everyone else who has this data its buried 6 levels deep in a large organization. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Hi Alan Thanks a lot for your comments. I guess you understand that I am always a bit nervous when the results of non-public conversations dictate the problem space. I have seen it often enough that people have made their measurements wrong, had wrong configuration, or had simply misunderstood concepts. It sounds like we need a "myth-busting" document. Of course, it isn't certain whether the decision makers will indeed read RFCs but it would be worthwhile a try. Also it appears that the authors could do something really actionable here, namely to update the hostap code to update the roundtrip limit. Ciao Hannes PS: Why aren't you a co-author on this document? You know more about this than anyone else. -Original Message- From: Alan DeKok Sent: Tuesday, March 24, 2020 3:08 PM To: Hannes Tschofenig Cc: Michael Richardson ; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig wrote: > 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. The issue is that deployment issues are usually discussed privately. One public link is this: http://freeradius.1045715.n5.nabble.com/Free-Radius-problem-with-sending-large-certificate-chains-using-EAP-TLS-td2780319.html >> 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. Maybe "can be large" and "can be long". It's difficult to get quantitative numbers here. I didn't instrument my software to send statistics back to a central collector. :( > >> 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. The peer often has a client certificate. So it's chain can be one longer than the server in some cases. > 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. Please tell that to corporations. :( I can't count how many times I've had to tell people "the technology doesn't support that", when they explain their business requirements. It is often difficult to get people to understand that their preferred process / methods are simply impossible to implement in the real world. >> 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. I'm not sure what else could be said here. >> The EAP fragment size >> in typical deployments is just 1020 - 1500 octets. > > Reference for the 1500 octets. Ethernet maximum packet 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? References to hostap source code. >> However, deployment >> experience has shown that these jumbo frames are not always >> implemented correctly. > > Add a reference here. Private communication. :( i.e. I've mediated calls between multiple large companies all pointing the finger at each other when things don't work. The solution was to point out that one particular networking box was simply dropping jumbo EAPoL frames. Names will not be used here. >> RADIUS can generally transport only about 4000 octets of EAP in a >> single message. > > How was this number constructed? 4K RADIUS maximum packet size. Minus 20 bytes for the RADIUS header overhead, 18 for Message-Authenticator, and for whatever other random things the AP vendor includes in packets. > I am also wondering what you are trying to say here with this > sentence. Are you saying that you hav
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig wrote: > 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. The issue is that deployment issues are usually discussed privately. One public link is this: http://freeradius.1045715.n5.nabble.com/Free-Radius-problem-with-sending-large-certificate-chains-using-EAP-TLS-td2780319.html >> 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. Maybe "can be large" and "can be long". It's difficult to get quantitative numbers here. I didn't instrument my software to send statistics back to a central collector. :( > >> 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. The peer often has a client certificate. So it's chain can be one longer than the server in some cases. > 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. Please tell that to corporations. :( I can't count how many times I've had to tell people "the technology doesn't support that", when they explain their business requirements. It is often difficult to get people to understand that their preferred process / methods are simply impossible to implement in the real world. >> 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. I'm not sure what else could be said here. >> The EAP fragment size >> in typical deployments is just 1020 - 1500 octets. > > Reference for the 1500 octets. Ethernet maximum packet 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? References to hostap source code. >> However, deployment >> experience has shown that these jumbo frames are not always >> implemented correctly. > > Add a reference here. Private communication. :( i.e. I've mediated calls between multiple large companies all pointing the finger at each other when things don't work. The solution was to point out that one particular networking box was simply dropping jumbo EAPoL frames. Names will not be used here. >> RADIUS can generally transport only about 4000 >> octets of EAP in a single message. > > How was this number constructed? 4K RADIUS maximum packet size. Minus 20 bytes for the RADIUS header overhead, 18 for Message-Authenticator, and for whatever other random things the AP vendor includes in packets. > 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? Yes. >> 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? An indication that *what* has gone wrong? Nothing in any of the current specs indicates that a 60KB certificate chain would be a problem. I suspect few AP / OS vendors discuss that in their documentation, too. > Is this someone you have observed or is this just a theoretical statement? I > hope it is the latter. It's observed. >> 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. Sure. This should be explained. >> 4.2.5. Using Fewer Intermediate
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
> On 24 Mar 2020, at 10:30, Hannes Tschofenig wrote: > > Hi Eliot, > > I consider the enterprise and the university case as a roaming model. From an > EAP method point of view there is IMHO little difference between the roaming > and the non-roaming case: the EAP exchange always runs between the EAP peer > on the device and the EAP server. > > The IoT case is different because it falls more in the category of home WiFi > usage. This doesn’t really use EAP in my understanding. For wifi? The number of IoT devices using wifi is minuscule compared to what I believe we will see over time. And so it is hard to judge. The onboarding mechanisms need to mature a bit more. Eliot___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Hi Eliot, I consider the enterprise and the university case as a roaming model. From an EAP method point of view there is IMHO little difference between the roaming and the non-roaming case: the EAP exchange always runs between the EAP peer on the device and the EAP server. The IoT case is different because it falls more in the category of home WiFi usage. This doesn’t really use EAP in my understanding. Ciao Hannes From: Eliot Lear Sent: Tuesday, March 24, 2020 10:24 AM To: Hannes Tschofenig Cc: Michael Richardson ; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Hi Hannes On 24 Mar 2020, at 10:08, Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> wrote: Hi Eliot You bring up a good point, namely the deployment environment. Are we are talking about an IoT, an enterprise deployment environment or something else? Clearly there will be differences. Reading through the text my impression was that this is about an enterprise (or university) deployment environment. I might, however, be on the wrong track here. Since we’re talking about EAP, I can think of a few cases: * Classic enterprise/university case, IoT or not. I was ASSUMING IoT because my brain goes to IOT, but I don’t think it has to be so. * There is also a wifi roaming device model, where EAP might be used in various service provider or federated environments a’la Eduroam or similar. Today this is NOT a big IoT space, but soon? The one place this is not a big deal at the moment is in the home, as WPA-Personal/PAE is the norm. One additional question is how big the impact is between wired and wireless. Obviously with the former you worry less about interference and drops. Eliot Having the references to where deployment problems with large certificates/certificate chains occur would shine light on this aspect. Ciao Hannes From: Eliot Lear mailto:l...@cisco.com>> Sent: Tuesday, March 24, 2020 10:02 AM To: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> Cc: Michael Richardson mailto:mcr+i...@sandelman.ca>>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Good morning Hannes 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. Not sure I entirely understand you. A few places are promoting new roots for manufacturers. And so the initial chain for a peer might look like CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it may be possible to remove one of the intermediates, but probably not both. It seems to me that this is an onboarding problem, and the best way to reduce the cert chain size on a day to day basis would be to swap out for an operational cert where the trust anchor is within the enterprise. That means you get one of those Big Fat transactions and then things settle down, and that transaction may be handled specially anyway. One comment I have in the draft relates to this text: o Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate. This statement is just a little too general. It very much depends WHICH certificate we are discussing. If it is a manufacturer certificate, as long as you can roll to an enterprise cert, then who cares? If it is an enterprise certificate, then we have to look more closely. So for instance, as Hannes mentions, authorization is a big issue. Some of that can be done outside of the certificate using ACE or similar, but some may need to be present in the cert. What we would rather not have is people working the SAN to introduce authorization attributes. Eliot 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. 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
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Hi Hannes > On 24 Mar 2020, at 10:08, Hannes Tschofenig wrote: > > Hi Eliot > > You bring up a good point, namely the deployment environment. Are we are > talking about an IoT, an enterprise deployment environment or something else? > Clearly there will be differences. Reading through the text my impression was > that this is about an enterprise (or university) deployment environment. I > might, however, be on the wrong track here. Since we’re talking about EAP, I can think of a few cases: Classic enterprise/university case, IoT or not. I was ASSUMING IoT because my brain goes to IOT, but I don’t think it has to be so. There is also a wifi roaming device model, where EAP might be used in various service provider or federated environments a’la Eduroam or similar. Today this is NOT a big IoT space, but soon? The one place this is not a big deal at the moment is in the home, as WPA-Personal/PAE is the norm. One additional question is how big the impact is between wired and wireless. Obviously with the former you worry less about interference and drops. Eliot > > Having the references to where deployment problems with large > certificates/certificate chains occur would shine light on this aspect. > > Ciao > Hannes > > From: Eliot Lear > Sent: Tuesday, March 24, 2020 10:02 AM > To: Hannes Tschofenig > Cc: Michael Richardson ; emu@ietf.org > Subject: Re: [Emu] My review ... was RE: I-D Action: > draft-ietf-emu-eaptlscert-02.txt > > Good morning Hannes > > > > > > 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. > > Not sure I entirely understand you. A few places are promoting new roots for > manufacturers. And so the initial chain for a peer might look like > CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it > may be possible to remove one of the intermediates, but probably not both. > It seems to me that this is an onboarding problem, and the best way to reduce > the cert chain size on a day to day basis would be to swap out for an > operational cert where the trust anchor is within the enterprise. That means > you get one of those Big Fat transactions and then things settle down, and > that transaction may be handled specially anyway. > > One comment I have in the draft relates to this text: > >o Extensions are necessary to comply with [RFC5280], but the vast > majority are optional. Include only those that are necessary to > operate. > > This statement is just a little too general. It very much depends WHICH > certificate we are discussing. If it is a manufacturer certificate, as long > as you can roll to an enterprise cert, then who cares? If it is an > enterprise certificate, then we have to look more closely. > > So for instance, as Hannes mentions, authorization is a big issue. Some of > that can be done outside of the certificate using ACE or similar, but some > may need to be present in the cert. What we would rather not have is people > working the SAN to introduce authorization attributes. > > Eliot > 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
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Hi Eliot You bring up a good point, namely the deployment environment. Are we are talking about an IoT, an enterprise deployment environment or something else? Clearly there will be differences. Reading through the text my impression was that this is about an enterprise (or university) deployment environment.. I might, however, be on the wrong track here. Having the references to where deployment problems with large certificates/certificate chains occur would shine light on this aspect. Ciao Hannes From: Eliot Lear Sent: Tuesday, March 24, 2020 10:02 AM To: Hannes Tschofenig Cc: Michael Richardson ; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Good morning Hannes 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. Not sure I entirely understand you. A few places are promoting new roots for manufacturers. And so the initial chain for a peer might look like CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it may be possible to remove one of the intermediates, but probably not both. It seems to me that this is an onboarding problem, and the best way to reduce the cert chain size on a day to day basis would be to swap out for an operational cert where the trust anchor is within the enterprise. That means you get one of those Big Fat transactions and then things settle down, and that transaction may be handled specially anyway. One comment I have in the draft relates to this text: o Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate. This statement is just a little too general. It very much depends WHICH certificate we are discussing. If it is a manufacturer certificate, as long as you can roll to an enterprise cert, then who cares? If it is an enterprise certificate, then we have to look more closely. So for instance, as Hannes mentions, authorization is a big issue. Some of that can be done outside of the certificate using ACE or similar, but some may need to be present in the cert. What we would rather not have is people working the SAN to introduce authorization attributes. Eliot 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
Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
Good morning Hannes > > >> 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. Not sure I entirely understand you. A few places are promoting new roots for manufacturers. And so the initial chain for a peer might look like CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it may be possible to remove one of the intermediates, but probably not both. It seems to me that this is an onboarding problem, and the best way to reduce the cert chain size on a day to day basis would be to swap out for an operational cert where the trust anchor is within the enterprise. That means you get one of those Big Fat transactions and then things settle down, and that transaction may be handled specially anyway. One comment I have in the draft relates to this text: o Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate. This statement is just a little too general. It very much depends WHICH certificate we are discussing. If it is a manufacturer certificate, as long as you can roll to an enterprise cert, then who cares? If it is an enterprise certificate, then we have to look more closely. So for instance, as Hannes mentions, authorization is a big issue. Some of that can be done outside of the certificate using ACE or similar, but some may need to be present in the cert. What we would rather not have is people working the SAN to introduce authorization attributes. Eliot___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt
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. > 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? > 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. 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. >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. > 4.2.5. Using Fewer Intermediate Certificates > The
