>>>>> "David" == David Mitton <[log in to unmask]> writes:
David> Since there isn't an author attribution on this document, I'm
David> not sure whom to direct this too....
David> In section 6.1, Negotiating the EAP Method, the statement is
David> made that "the NAS needs to know what EAP method to use."
David> This is incorrect. The NAS does not, in fact it really
David> should not, it would break layering.
That statement is made in a paragraph explaining why negotiating the EAP
method to use at the GSS-API layer would be problematic in an EAP/RADIUS
environment. In context, in order to negotiate which eap method to use
at the GSS-API layer, the NAS needs to know which EAP method to use so
that it can advertize it in the GSS-API OID. The paragraph then goes on
to explain some of the reasons why this is impossible to implement with
the current RADIUS protocol.
The analysis was never contemplating having the NAS inspect EAP
messages. The text suggests extending RADIUS to advertize a set of EAP
type code before EAP starts. It points out that doesn't actually work,
although it misses some of the critical reasons it doesn't work. (It
does include enough to demonstrate that approach is problematic though).
You're absolutely right that having a NAS
inspect the type codes of EAP messages, or restricting the set of EAP
methods the NAS can work with would defeat the entire point of making
the NAS EAP-method agnostic.
The conclusion that section then draws is that the traditional GSS-API
solution to the multi-layer negotiation problem is problematic in an
EAP/GSS environment.
The specification (draft-howlett-eap-gss) discusses this issue in more
detail and concludes that multi-layer negotiation is required.
|