h Salowey mailto:jsalo...@cisco.com>>
Cc: "emu@ietf.org<mailto:emu@ietf.org>" mailto:emu@ietf.org>>
Subject: [Emu] A review Re: [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt
Section 1
"The other type of PT, PT-TLS [I-D.ietf-nea-pt-tls], operates before the
endpoin
> "Joe" == Joe Salowey 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
> On Jun 6, 2012, at 12:09 PM, Sam Hartman wrote:
>
> > 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 ac
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
c
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
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 suc
