On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote:
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact that something is the kind of thing the IETF
On 8/26/2011 1:13 PM, Dan Harkins wrote:
On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote:
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact that
On 8/26/2011 1:27 PM, Glen Zorn wrote:
...
Hardly. The fact that the IETF was busy a) insisting that there was no,
and never would be, any need for dynamic key generation (let alone
mutual authentication) in network access protocols (specifically PPP;
how could there be, since the only
On Thu, August 25, 2011 11:27 pm, Glen Zorn wrote:
On 8/26/2011 1:13 PM, Dan Harkins wrote:
On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote:
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example
Dan:
1) My desire to use GPSK with anonymous server authentication is more or
less unrelated to any other part of this discussion. I want to be able
to do it because I think I might deploy it and I don't want the spec to
forbid a deployment I consider reasonable. There is no security
Sam,
On Thu, August 25, 2011 8:35 am, Sam Hartman wrote:
Dan:
1) My desire to use GPSK with anonymous server authentication is more or
less unrelated to any other part of this discussion. I want to be able
to do it because I think I might deploy it and I don't want the spec to
forbid a
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact that something is the kind of thing the IETF
standardizes but is never the less informational should
Dan == Dan Harkins dhark...@lounge.org writes:
Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method.
I support all of dan's changes regarding unauthenticated server mode
with the exception of the quoted text above. I do not generally support
a down-reference to an informational
On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote:
Dan == Dan Harkins dhark...@lounge.org writes:
Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method.
I support all of dan's changes regarding unauthenticated server mode
with the exception of the quoted text above. I do not
Dan == Dan Harkins dhark...@lounge.org writes:
Dan On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote:
Dan == Dan Harkins dhark...@lounge.org writes:
Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method.
I support all of dan's changes regarding
Hello,
The tunnel method draft indicates that an anonymous TLS ciphersuite
should only be used in accordance with the server unauthenticated
provisioning mode described in RFC 5422. This is unfortunate because
the technique described in RFC 5422 requires changes to an existing
EAP method,
11 matches
Mail list logo
