Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT)

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 25 Sep 2013 06:21:24 +0000

On Aug 14, 2013, at 10:58 AM, Stephen Farrell <[email-masked]> wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-emu-eap-tunnel-method-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> These discuss points are more questions I'd really like
> answered than blocking points (depending on the answers I
> guess:-) but I expect should be easily resolved.
> 
> (1) 3.4: when x.500 names or SubjectAltNames are
> "exported" is it clear how those are formatted? Maybe a
> pointer to where that's defined would be good in case
> implementers get it wrong. You might also want to warn
> here (or somewhere) about names that contain a null byte
> in case that attack is used e.g. with a TLS server cert
> subject name like "CN=www.paypal.com\0.badguy.com" Even
> though that's really a PKI failure, not detecting it here
> would be bad too.
> 

[Joe]  We could add a note about the null, is there some text in an existing document we could reuse?  

> (2) 5.2, at the end: this adds a dependency on the
> TLS-PRF.  I don't suppose TLS1.3 will be a big enough
> change for that to be a problem, but what if it was? E.g.
> if someone convinced the TLS WG to use IKE instead? Do
> you really need the same PRF or could you pick one for
> TEAP and remove the dependency? Same question for the MAC
> in 5.3.
> 

[Joe] We chose to have the dependence so we would rely on the same crypto-algorithms as TLS so our crypto agility would track with TLS.   We figured TLS would track advances in cryptography better than EMU. 

> (3) 7.3: you have a MAY for this separation but also
> define what would become a cleartext password set of TLVs
> on the link between the two boxes here. Could you not at
> least REQUIRE protection (e.g. using IPsec) of that link
> if the basic password method will be used?
> 

[Joe] Sam's comments pretty much reflect the working group consensus on this topic. 

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - 3.2: You're allowing TLS compression. Is there the
> potential for something like a CRIME attack here? I guess
> not, given that there's no way to programatically get a
> peer or inner method server to send attacker-chosen data.
> Is that correct? (Just checking.)
> 

[Joe] In general no.  The closest thing I can think of is NEA which can use a method such as TEAP for transport, but I don't think this would allow an attacker to launch a CRIME attack. 

> - 3.2.2: Since a PAC-lifetime is a wall-clock time then
> it would provide a way to correlate old and new sessions
> (i.e. act as a fingerprint) if its ever carried in clear.
> Can that happen?
> 

[Joe] The PAC-lifetime is carried in the PAC-Info which is always send under the protection of the TLS tunnel.  Only the PAC-Opaque is sent outside the tunnel.

> - 3.3.3, 1st para: what does "clear text" mean here? Do
> you mean within the TLS tunnel or not? I hope you do mean
> within the TLS tunnel, but I think you need to be
> clear(er) in any case.
> 

[Joe] Clear text means outside the TLS tunnel.  EAP state machine requires that the EAP-Success or EAP-Failure be sent independently of the method.  This is why TEAP has its own protected result indication and why this section states that the Peer must not accept a cleartext success or failure before the protected results are received. 

> - 3.8: this says mutual auth "results" if the peer trusts
> the server cert belongs to the server - that sounds
> wrong, isn't it?
> 

[Joe] I think this section is terminology challenged.  It should basically replace mutual server authentication with just server authentication. 

   "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. "

> - 3.8.1: I think you need an s/MAY/MUST/ here - you say
> the request "MAY be issued only ..." but I think you mean
> "MUST be issued only..."
> 

[Joe] Yes.  How about:

"The peer  MUST successfully authenticated the EAP server and validated the Crypto-Binding TLV as defined in 
Section 4.2.13 before issuing the request"

> 
> - 3.8.2: Just checking, and I may be wrong here. Say if I
> establish a TLS server-auth tunnel and then renegotiate
> to get TLS client-auth (with id privacy) as well, and
> then the Peer wants to get a new cert.  This calls for
> the tls-unique for the initial server-auth TLS session to
> be used in the pkcs#10.  Am I reading it right? Is that
> ok? I think it is, but just want to check since its
> pretty confusing;-)
> 

[Joe] This is meant to use the same mechanism as EST.   It is currently out of sync with the latest version.   It should line up:

   In order to provide linking identity and proof-of-possession by
   including information specific to the current authenticated TLS
   session within the signed certification request, the peer generating
   the request SHOULD obtain the tls-unique value from the TLS subsystem as defined in Channel
   Bindings for TLS [RFC5929].  The TEAP peer operations between obtaining the tls_unique value
   through generation of the CSR that contains the current tls_unique
   value and the subsequent verification of this value by the TEAP server
   are the "phases of the application protocol during which application-
   layer authentication occurs" that are protected by the synchronization
   interoperability mechanism described in the Channel Bindings for TLS 
  [RFC5929] section 3.1 interoperability notes.  When performing renegotiation, 
  TLS "secure_renegotiation" [RFC5746] MUST be used.

   The tls-unique value is base 64-encoded as specified in 
   Section 4 of [RFC4648] and the resulting string is placed in the certification
   request challenge-password field ( [RFC2985], Section 5.4.1).  The
   challenge-password field is limited to 255 bytes (section 7.4.9 of [RFC5246]
 indicates that no existing cipher suite would result in an
   issue with this limitation).  If tls-unique information is not
   embedded within the certification request the challenge-password
   field MUST be empty to indicate that the peer did not include the
   optional channel-binding information (any value submitted is verified
   by the server as tls-unique information).

   The server SHOULD verify the tls-unique information.  This ensures that the authenticated TEAP
   peer is in possession of the private key used to sign the
   certification request.

> - The secdir review [1] raised a couple of questions that
> I think would be good to answer. Did I miss that answer?
> 

[Joe] No, I missed the review.  Response in progress.  

>   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu