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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Sent: Monday, December 17, 2007 9:10 AM
To: secdir(_at_)mit(_dot_)edu; 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf