It seems to me, the consistency between EAP peer and EAP Server can be caused
by the Lying NAS
Even this NAS is not malicious authenticator who impersonates another
authenticator, this NAS should
be a stupid NAS or malfunctional NAS who make a mistake for some reason.
Because this NAS distribu
Bernard Aboba wrote:
> Do we really need “IESG clarification” or a “consensus check” to verify
> that IESG approval of a work item for channel bindings should be
> interpreted as approval to actually work on channel bindings???
No.
> Given that Channel Bindings is discussed in both RFC 3748 and
There are 3 parties in the AAA/EAP exchange. Not every party is
authenticated in the exchange (e.g. the NAS/AAA client is not
authenticated by the EAP peer) -- there is only key confirmation taking
place.
The NAS can therefore report different identities to the EAP client and
to the AAA server.
> The discussion here is (a) if we can get *some* generic authorization
> passed via methods used for Channel Bindings, and (b) is that a good idea.
>
> I think that the answer to (a) is "yes", and (b) is "some say yes,
> some say no".
Existing RFCs are clear that Channel Bindings have a spe
Qin said:
"Based on this, impersonation issue seems to overlap with channel binding or
lying NAS issue."
RFC 3748 Section 7.15 describes the distinction between the two problems:
" Section 4.3.7 of [RFC3579] describes how an EAP pass-through
authenticator acting as a AAA client can be det
The problem is that the internationalization language is too general.
For example, Section 4.3.6 states:
" Any strings sent by the server intended for display to the user MUST
be sent in UTF-8 format and SHOULD be able to be marked with language
information and adapted to the user's la
