Re: [secdir] SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt

["Joseph Salowey (jsalowey)" <[e-mail]>]

Hi Chris,

Thanks for the review, I missed it earlier.  responses inline below:


On Jul 24, 2013, at 9:44 AM, Chris Lonvick <[e-mail]> wrote:

> Hi,
> 
> 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 the document is well written and I found it to be complete. Since the document is a bit on the long side, I focused on sections 1 through 3, and 7.  I scanned sections 4, 5, and 6.  I did not review the Appendixes.  I did have a couple of issues that I want to raise:
> 
> In Section 3.6.1, point #2 says that the TEAP packet is to be "ignored" if the other fields are "wrong".
> - What does "wrong" mean?

[Joe] Wrong means inconsistent with the rest of the specification.  new text:

"The entire TEAP packet will be ignored if other fields (version, length, flags, etc.) are inconsistent with this specification."

> - Also, I'd like to see some more clarification of what is expected from the carrier protocol if the TEAP packet is "ignored".  Wouldn't the carrier protocol just attempt redelivery if it doesn't get some sort of acknowldegement of the delivery of the TEAP packet?
> 

[Joe] Yes, this is aligned with the behavior in RFC 3748.  THis will result in a timeout and termination of the conversation. 

> Section 3.8 (second paragraph) says:
>  >  TEAP implementations SHOULD have
>  > a configuration where authentication fails if mutual authentication
>  > cannot be achieved.
> My personal feeling is that the SHOULD should be replaced with a MUST, but I acknowledge that is an implementation detail.  I then went looking for a discussion of this in the Security Considerations section and found 7.1 on "Mutual Authentication and Integrity Protection".  However I couldn't find anything in that section on Mutual Authentication.  Would you please add some discussion to that section on the problems that could arise if an implementation does not have mutual authentication?
> 

[Joe] The terminology in this section is misleading.  It states peers must mutually authenticate the server and the rest of the section should refer to server authentication new text:

 "Several TEAP services including server unauthenticated provisioning,
  PAC provisioning, certificate provisioning and channel binding depend
  on the peer trusting the TEAP server.  Peers MUST 
  authenticate the server before these peer services are used.

  TEAP peers MUST track whether server authentication has taken place.
  Server authentication results if the peer trusts the provided server
  certificate. Typically this involves both
  validating the certificate to a trust anchor and confirming the
  entity named by the certificate is the intended server.  Server
  authentication also results when the procedures of Section 3.3 are
  used to resume a session in which the the peer and server was
  previously mutually authenticated.  Alternatively, if an inner EAP
  method providing mutual authentication and an Extended Master Session
  Key (EMSK) is executed and cryptographic binding with the EMSK
  compound MAC is present (Section 4.2.13), then the session is
  mutually authenticated and peer services can be used.  

  TEAP implementations SHOULD NOT use peer services by default unless the
  session is server authenticated.  TEAP peer implementations MUST have
  a configuration where authentication fails if server authentication
  cannot be achieved.

  An additional complication arises when a tunnel method authenticates
  multiple parties such as authenticating both the peer machine and the
  peer user to the EAP server.  Depending on how authentication
  is achieved, only some of these parties may have confidence in it.
  For example if a strong shared secret is used to mutually
  authenticate the user and the EAP server, the machine may not have
  confidence that the EAP server is the authenticated party if the
  machine cannot trust the user not to disclose the shared secret to an
  attacker.  In these cases, the parties who participate in the
  authentication need to be considered when evaluating whether to use
  peer services. "

> 
> I also found a few nits that you may want to look at.
> 
> You mostly use "Type-Length-Value" but you have one instance of "Type Length Value".
> 
> Section 3.1 says,
>   > MUST use a version field set to 1.
> Throughout section 4 you sometimes use "set to 1", and sometimes use "set to zero (0)", and in a few cases "set to (1)".  This inconsistency just set my OCD value to one (1).  ;-)
> 
> Section 3.3
>   > If the server ignores the
>   > request, it proceeds with termination of the tunnel and send the
>   > clear text EAP Success or Failure message based on the Status field
>   > of the peer's Request-Action TLV.
> Maybe:
>   If the server ignores the
>   request, it proceeds with termination of the tunnel and sends the
> or "will send".
> 
> Typo in section 3.8.4
>   > after it has succ;essfully authenticated the server and established
> 
> Section 7
>   > greater.  The threat model used for the security evaluation of TEAP
>   > is defined in the EAP [RFC3748].
> Maybe just "defined in EAP [RFC3748].", or "defined in the security consideration section in EAP [[RFC3748]."
> 
> 

[Joe] Thanks, I'll address these. 

> Regards,
> Chris