Re: [Emu] EAP and authorization

[Stefan Winter <stefan.winter at restena.lu>]

Hello,

>> That's the straightforward approach.   It avoids the need to cling to
>> alternate definitions of well understood terms.  If you need to re-charter
>> to gain that authority, then so be it.  IMHO, this whole discussion looks
>> like an end-run around the "domain of applicability" restrictions for EAP.
>>     
>
>   I agree it does look that way.  I don't even think that's a wrong
> characterization of the issue.
>   

It also reminds me of the discussion in radext prior to the last
re-charter, when "No new security mechanisms will be defined for RADIUS"
but at the same time crypto-agility and keywrap lay on the table. There
were lengthy and at times seemingly far-fetched arguments on why this
would or would not be permitted by the charter. In the end, things were
clarified by issuing a new charter and everybody lived happily ever
after (well, sortof ...).

>> Shall we take the high road here?  At the very least, you could seek
>> clarification from the IESG as to whether they think that the current
>> "domain of applicability" for EAP embraces the "additional data" you want to
>> include.  After all, enforcement of "applicability statements" is a very hit
>> or miss thing in the IETF.  You may get lucky.  :-)
>>     
>
>   I would prefer to get WG consensus first.  If the WG believes it's a
> good idea, the re-chartering process becomes simpler.
>   

I think it's a good idea to acknowledge the reality that transport of
authorization data happens right now in EAP methods.
I also think it's a good idea to have both authentication and
authorization data in EAP.
If a re-charter were to acknowledge that EMU is also allowed to work on
authorization, I think we might end up with a way cleaner, proper
approach to handle authorization in EAP (which might end Dave's
perceived inappropriateness of it). Having an encrypted channel to
exchange authorization information post-authentication, even if the
authentication does not set up a tunnel for it comes to mind. That way,
the EAP conversation could for example always carry NEA information,
agnostic of the protocol used in the prior authentication phase.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473