Subject: Re: secdir review of draft-simon-emu-rfc2716bis-11.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Dec 2007 11:33:21 -0800

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:[email-masked]]
> Sent: Monday, December 17, 2007 9:10 AM
> To: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf