Subject: Re: [Emu] [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt

From: Joe Salowey <[email-masked]>
Date: Tue, 5 Jun 2012 11:05:11 -0700

June 4 has come and gone and we haven't received any comments.  If you have reviewed the document and not found any issues please indicate that on the list.  I'll leave the review open until 6/12.  If you can commit to review the document, please let me know.  

Thanks,

Joe
On May 21, 2012, at 2:01 PM, Joe Salowey wrote:

> The NEA working group has produced a draft for carrying NEA posture methods within EAP.  It would be helpful if some EMU working group members reviewed the draft.   Please send your comments to the EMU list by June 4, 2012.
> 
> Thanks,
> 
> Joe
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Date: May 15, 2012 8:36:14 AM PDT
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Endpoint Assessment Working Group of the IETF.
>> 
>> 	Title           : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods
>> 	Author(s)       : Nancy Cam-Winget
>>                         Paul Sangster
>> 	Filename        : draft-ietf-nea-pt-eap-02.txt
>> 	Pages           : 20
>> 	Date            : 2012-05-15
>> 
>>  This document specifies PT-EAP, an EAP based Posture Transport (PT)
>>  protocol designed to be used only inside a TLS protected tunnel
>>  method.  The document also describes the intended applicability of
>>  PT-EAP.
>> 
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-02.txt
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-02.txt
>> 
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/
>> 
>> _______________________________________________
>> Nea mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nea
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: [email-masked]
Date: Wed, 6 Jun 2012 17:18:22 +0800

Section 1
"The other type of  PT, PT-TLS [I-D.ietf-nea-pt-tls], operates before the 
endpoint gains
   any access to the IP network. "
==>should be "after the endpoint have gained access to the IP network"

"PT-EAP is an inner EAP [RFC3748] method designed to be used under a
   protected tunnel such as TEAP [I-D.ietf-emu-eap-tunnel-method], EAP-
   FAST [RFC4851] or EAP-TTLS [RFC5281]."
==>PEAP is more widely supported.

"Finally, it describes how the  tls-unique channel binding [RFC5929] may 
be used to PA-TNC exchanges
   to the EAP tunnel method, defeating MITM attacks such as the Asokan 
attack [Asokan]."
==>

"Some EAP tunnel methods may provide explicit confirmation of inner method 
success; others may not. "

section 3.4 " Attack Analysis [16], " the reference [16] 

section 4.2.3
"The strong integrity protections (hashing) offered by EAP-TTLS allows the
   PT-EAP message recipients to detect message alterations by other
   types of network based adversaries. "
===>it is not hashing offering the integrity, but MAC
section 4.2.4
" the  session can be encrypted and hashed to prevent undetected
   modification that could create a denial of service situation.
"
===> only MAC, not encryption and hashing can prevent modification

section 4.3
  "The phase two dialog may include authentication of the user by doing
   other EAP methods or in the case of TTLS by using non-EAP
   authentication dialogs.  PT-EAP is also carried by the phase two
   tunnel allowing the NEA assessment to be within an encrypted and
   integrity protected transport."
==> TTLS can also use EAP method as inner method.

"These inner methods may perform additional security handshakes including 
more
   granular authentications or exchanges of integrity information (such
   as PT-EAP.)  "
===> IMO，PT-EAP better be exchanged after the phase two of the EAP tunnel 
method, so that
 the resulted key derived from tunnel and inner authentication method can 
be used to protect it. 

section 5
  "To support countermeasures against NEA Asokan attacks as described in
   Section 3.4, the EAP Tunnel Method used with PT-EAP will need to
   support the tls-unique channel binding.  This should not be a high
   bar since all EAP tunnel methods currently support this but not all
   implementations of those methods may do so."
====> It seem no current EAP tunnel support tls-unique now.
  And Asokan MitM attack is countered by crypto binding, where tunnel 
method is bound with inner method.
  While TLS-unique is limited to the tunnel method to provide binding 
between TLS and application, I wonder 
  if there is some confusion in the document. 

Regards~~~

-Sujing Zhou

Joe Salowey <[email-masked]> 
发件人:  [email-masked]
2012-06-06 02:05

收件人
[email-masked]
抄送

主题
Re: [Emu] [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt

June 4 has come and gone and we haven't received any comments.  If you 
have reviewed the document and not found any issues please indicate that 
on the list.  I'll leave the review open until 6/12.  If you can commit to 
review the document, please let me know. 

Thanks,

Joe
On May 21, 2012, at 2:01 PM, Joe Salowey wrote:

> The NEA working group has produced a draft for carrying NEA posture 
methods within EAP.  It would be helpful if some EMU working group members 
reviewed the draft.   Please send your comments to the EMU list by June 4, 
2012.
>> A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Network Endpoint Assessment 
Working Group of the IETF.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jun 2012 15:09:47 -0400

I don't believe that existing crypto binding is adequate for NEA's needs
as discussed in draft-hartman-emu-mutual-crypto-binding.

Unfortunately, though, I'm not sure that tls-unique helps enough  here. If
the outer method actually does provide server authentication as
deployed, then tls-unique is adequate.  TLS-unique is preferable to
crypto-binding because it allows you to determine whether you're talking
about the right tunnel in the scope of the inner method--prior to doing
the NEA assessment--rather than in the scope of the outer method. (Also,
I'd assume this method does not generate a particularly useful key, so
crypto binding is not that helpful)

However, if you're depending on something other than the outer method
for server authentication, then TLS-unique is not good enough.

---

From: Joe Salowey <[email-masked]>
Date: Wed, 6 Jun 2012 16:59:20 -0700

So, is your concern with using only MSK crypto binding with an  inner EAP authentication method used to authenticate an unauthenticated/poorly authenticated tunnel or is it more specific to the nea-pt-eap method? 

For the first concern it may be sufficient to discuss the issue in the security considerations.

If the concern is more about specifics of TLS-unique in nea-pt-eap not being adequate then we need to better understand what the concern is.  I don't think the goal of the TLS-unique in nea-pt-eap is to provide server authentication, rather its to prevent the nea data from being used in a context different than it was generated. 

Thanks,

Joe

---

From: [email-masked]
Date: Thu, 7 Jun 2012 09:27:48 +0800

> > the NEA assessment--rather than in the scope of the outer method. 
(Also,
But it said nea-pt-eap might come right after an inner EAP method, 
so crypto binding might be needed to bind tunnel and inner methods.

tls-unique in the draft is used in higher layer (by broker) to bind the 
EAP tunnel channel with
application layer.

> > crypto binding is not that helpful)
As far as　I know， the nea-pt-eap method is not an authentication method, 
it is just used to transfer information, similar to EAP Identity
> > for server authentication, then TLS-unique is not good enough.
The secure transfer of nea-pt-eap depends entirely on EAP tunnel method, 
so
the EAP tunnel method is required to provide strong authentication, 
integrity and confidentiality protection. 

Sujing Zhou

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jun 2012 09:02:57 -0400

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

    Joe> So, is your concern with using only MSK crypto binding with an  inner EAP authentication method used to authenticate an unauthenticated/poorly authenticated tunnel or is it more specific to the nea-pt-eap method? 
    Joe> For the first concern it may be sufficient to discuss the issue in the security considerations.

Sounds good to me and that is my concern.

I see no reason EAP-PT needs more text than what we did for the cb
draft.