Sam,
         Let me start by saying I do believe you have an issue here.

My original objection was to how the problem was described
"the NAS needs to know what EAP method to use"
Even given some situational license, this is not a NAS problem in general,
but with your NAS application.
(and my comment about layering wasn't meant to be a suggestion, but a
warning why that would be a bad idea)

But if I back up a second, I don't believe that is true either.
If your NAS did the appropriate thing by the EAP/AAA architecture, it
would simply pass through the EAP method negotiation to the client.
And it would be a negotiation between the EAP supplicant/client(peer)
and EAP server(authenticator) where the method selection would get resolved.
The NAS is a transparent man-in-the-middle.

I have no experience with GSS-API, so I cannot directly evaluate how
this differs from "the traditional GSS-API solution",
but I can guess you have an issue, where you want to
present a dynamic list of known EAP methods without prior knowledge.

Even if you could get the active EAP methods, you have another problem,
in that just because an EAP method can be serviced on a given AAA 
authenticator,
it doesn't mean it will support your credentials for the given user.
For example, my typical RADIUS server setup will have configured EAP methods:
PEAP w/MS-CHAP and EAP-POTP (RSA tokens), but if use POTP and your account is
not in the RSA authentication server database, you will fail.

Typically, for remote access, it's a matter of knowing what auth 
protocol you have to use
to succeed.   The server itself supports a number of user groups, 
methods, and credentials for various situations.

Dave.



On 4/1/2010 04:47 PM, Sam Hartman wrote:
> >>>>> "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.