On 9/1/10 4:56 PM, "Sam Hartman" <[email protected]> wrote:
>>>>>> "Joe" == Joe Salowey <[email protected]> writes:
>
> Joe> The basic reason for this is that EAP methods have a well
> Joe> defined mechanism to output key material. There hasn't been a
> Joe> mechanism to import data into a method, channel bindings may
> Joe> change this.
>
> OK, but I'm not sure this quite gets you the properties you want.
>
[Joe] What we wanted from this mechanism was to ensure that the tunnel
endpoints was the same as the inner method endpoints.
> As best I can tell:
>
> * The server wants assurance that if an inner method is somehow lifted
> out of a tunneled exchange, the inner method cannot be used alone or
> in a different tunnel.
>
[Joe] We didn't want to modify the method. The purpose was to restrict the
method only to the a particular tunnel type, but we wanted to make sure that
the particular instance of method execution wasn't executed in a different
tunnel or without a tunnel.
> * The client wants assurance that it's talking to a consistent server so
> that you only end up having to authenticate the server at one level.
>
[Joe] For most cases the assumption is that the server is authenticated by
the tunnel method.
> Impersonating peers to servers and impersonating servers to peers both
> have value to an attacker in different situations.
>
> I think these are the properties you want (And I think the definition in
> RFC 3748 is a bit under specified) and I'm not sure how what you've
> described gets that.
[Joe] I'm not sure if I understand the properties you describe, so I'm not
sure if they line up with the goals of making sure the tunnel endpoints are
the same as the inner method endpoints.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
