Thank you for your detailed comments. I have produced an updated version of the document to address these and other IETF last call comments: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-12.txt Some responses below: - I assume that its correct to target this document at TLS 1.1 and not to consider any features that are part of TLS 1.2 which is at WGLC? Does TLS 1.2 cause any difficulties? 2.1.1 says "TLS v1.0 or later" so hopefully there aren't any issues. (I didn't check in detail.) [rmh] No I have reviewed TLS 1.2 and I see no issues. [ba] EAP-TLS can use TLS 1.0 or later. I am not aware of any issues with TLS v1.2. However, existing implementations have only been tested with TLS v1.1, so that is cited as the normative reference. - In the case of a session resume, SHOULD the client_hello contain exactly one ciphersuite? If more than one is ok there, why? (Since it says in section 2.1.1 that "If the session matches the client's, then the ciphersuite MUST match the one negotiated during the handshake protocol execution that established the session.") [ba] In EAP-TLS, the peer does not necessarily know whether it will encounter the same AAA server as before. As a result, an attempt to resume can fail, in which case the server will select among the ciphersuites offered by the peer. Therefore having the peer provide only a single ciphersuite can increase the chance of negotiation failure after an unsuccessful resume attempt. - In section 2.1.3 1st para, the server sends an alert " so as to allow the peer to inform the user of the cause of the failure..." What if there's no user? Is there a bit of applicability stuff missing here? (I'm assuming that this protocol could be used by devices like a wireless printer.) [rmh] Would a change to the effect of the following address this concern: "so as to allow the peer to inform the user or log of the cause of the failure..." [BA] Added. - 2.1.3, 2nd para. The anti-DoS limit to the number of restarts. Does that only apply per client or should there also be an overall limit on the number of outstanding "hanging" sessions? [BA] Added clarification about a per-client limit. - 2.1.3: should the peer re-use the same session id for a number of attempts when server authentication fails? I think one could argue that the peer SHOULD delete that session from its cache or whatever on the basis that the peer sending the TLS alert might expose some information. [BA] How about this? "If EAP server authentication is unsuccessful, the peer SHOULD delete the session from its cache, preventing reuse of the sessionId." - 2.1.4 says "In order to determine the privacy configuration on link layers (such as IEEE 802 wired networks) which do not support network advertisement, it may be desirable to utilize information provided in the server certificate or within identity selection hints [RFC4284] to determine the appropriate configuration." That seems overly vague - what information? (And I note that rfc4284 itself says that is limited to small scale networks.) [BA] Added mention of the subject and subjectAltName fields. - 2.1.5 says "However, in order to ensure interoperability with existing implementations, TLS handshake messages SHOULD NOT be fragmented into multiple TLS records if they fit within a single TLS record." (which is fine, except should it say "multiple EAP-Responses"?) Does that also mean that a set of TLS handshake messages SHOULD NOT be fragmented if they all fit in a single MTU? (i.e. would it be ok to split the TLS certificate, client_key_exchange from the change_cipher_spec and finished if all 4 would fit in a single EAP-Response?) [BA] The statement was about TLS records, not about EAP-TLS fragmentation. So it would be ok to split the TLS certificate, etc. messages even if it would fit in a single EAP-Response (although that would be inefficient). - 2.2 discusses when a certificate subject (or alt name?) is identical to the identity from an EAP-Response/Identity message. Is that comparison sufficiently well-defined? In particular the uri alt name choice might have some issues. (And a forward pointer to section 5.2 would be useful here.) [BA] The point being made in this section is that there is no need for such a comparison, because the EAP-Response/Identity is only used for routing purposes as described in RFC 3748. Added the forward reference. - Section 2.3 seems to describe a specific TLS extractor (as in draft-rescorla-tls-extractor). Would it be better to move (now or in future) to that more generic sheme? [rmh] Right now the goal of this effort is to document what implementations do today, changes such as this might make sense long term but are not compatible with that goal. - Would it make sense to align the mandatory ciphersuites with those being chosen for TLS 1.2? [rmh] The goal of the effort is to document what implementations do today. Since none of todays implementations are based on 1.2 we have retained the 1.1 mandatory ciphersuite. - Section 5.3 says "it must be pre-configured" - ought that be a MUST? (Same section has a lot of lowercase occurrences of "may") [BA] I don't think the intent is to specify a normative requirement in this case. How about this? "Where the EAP-TLS server is unable to retrieve intermediate certificates, it either will need to be pre-configured with the necessary intermediate certificates to complete path validation or it will rely on the EAP-TLS peer to provide this information as part of the TLS Handshake (see [RFC4346] section 7.4.6)." - Section 5.4 says the peer MUST be able to check cert status after network access is available. Presumably that should be done quickly and has to include all intermediate CA certs as well as the server cert? If one of those is revoked or no information is available what should the peer do? (Aside: is this really used?) [rmh] In our implementation we do post admission checks as well as OCSP in-band via the OCSP TLS extension however I am hesitate to over specify how this should be done, as different enviroments, scenarios and policies mandate different approaches and when it comes to the authoritative documents for revocation checking 2560, 5019 and 3280 are the authoritative documents. Editorial - It'd be good if the abstract said whether or not this is backwards compatible with RFC 2716 or not. Without having read 2716, I'm still not clear. [rmh] It is, and thats the intent; I am not apposed to further clarification. [BA] Added a statement to this effect in Section 1. - Seems a bit odd to specify the length, but nothing else for the MSK and EMSK in the terminology section. Saying less is probably easier. [BA] Removed mention of the length, since this is already stated in RFC 3748. - 2.1.1 says " While the EAP server SHOULD require client authentication, this is not a requirement, since it may be possible that the server will require that the peer authenticate via some other means." Using "require" three times there is odd. [BA] How about this? "While the EAP server SHOULD require client authentication, this is not mandatory, since there are circumstances in which client authentication will not be needed (e.g. emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means." - 2.1.2 2nd para uses the term NAS without expansion, "tunnel server" isn't defined and "rotary" and "remoted" aren't entirely clear. Suggest rewording this paragraph. [BA] How about this? "In the case where the EAP server and authenticator reside on the same device, then peer will only be able to continue sessions when connecting to the same authenticator. Should the authenticators be set up in a rotary or round-robin then it may not be possible for the peer to know in advance the authenticator it will be connecting to, and therefore which sessionId to attempt to reuse." - 2.1.3 3rd para says "verify the hash" without saying which hash. [BA] I presume we're talking about the Finished message, no? Do we need to state that explicitly? - 2.1.3 4th para "server authenticates unsuccessfully" is very odd wording [BA] How about "If EAP server authentication is unsuccessful..." - 2.1.4, 5th para says "MUST accept a client certificate" which is too strong, I guess what's meant is that they "MUST be able to accept..." since e.g. the client cert might be revoked. [rmh] Yes that is the intent, I am not opposed to the change. [BA] Done. - 2.1.5 is "may be desirable" right? That paragraph seems a bit vague overall. [rmh] Yes, that is an ok change. [BA] Are we talking about the second paragraph? Is there a suggested change in the text? " In order to protect against reassembly lockup and denial of service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a single certificate is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB." - Sections 5.3 and 5.4 seem more like protocol than security considerations. If it were easily do-able, I suggest moving those to somewhere in section 2. [BA] Making this big a change could introduce unintended consequences, so I'm wary of it. typos: - Intro, 2nd para, s/a EAP peer/an EAP peer/ - Indenting of 1.2 is wrong - 2.1.1 s/then client/then the client/ - 2.1.3 s/message rather immediately/message immediately/ - 2.1.3 s/If the peers authenticates/If the peer authenticates/ - 2.1.4 has a lower case "should" that I think ought be SHOULD? [BA] Fixed. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > Sent: Monday, December 17, 2007 9:10 AM > To: secdir@xxxxxxx; Ryan Hurst; Bernard Aboba; Dan Simon > Cc: Salowey, Joe; Sam Hartman > Subject: secdir review of draft-simon-emu-rfc2716bis-11.txt > > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > Overall, there are at least some typos and editorial comments that I would say should be fixed and possibly a few technical issues. My review is attached. > > Regards, > Stephen. > |
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf