eap Mailing List: Re: Proposed Resolution to Issue 367: Key Scope and ServerAuthorization

[Bernard Aboba (bernard_aboba]

> I think the text below is good, but I don't think it addresses the issue
> I had in mind.
>
> Consider the case where each authenticator contains its own EAP Server.
> If the peer wants to ensure that it is connecting to the "correct"
> authenticator it obviously cannot just rely upon channel bindings since
> the authenticator is in control of the EAP server, it must be able to
> authorize the EAP server as being able to authorize the authenticator.
> If we consider a remote EAP Server then this EAP server will be
> authorized to authorize a subset of authenticators.  In order for a
> peer to verify that the authenticator in collusion with the EAP server
> is not lying about some parameter it must be able to authorize the EAP
> Server as being able to authorize the authenticator.
>
> In some ways this is a basic thing, but I don't think this is currently
> covered elsewhere in the document.  It may not belong in this section,
> but I think it belongs somewhere with the scoping discussion.
>
>
> Joe

When the EAP method exports the Server-Id, and the claim of server identity 
is authenticated (such as via certificates) the peer can decide whether the 
EAP server is authorized or not.   As you note, channel bindings only apply 
when the EAP server can be trusted.  By the principle of mode independence, 
the peer doesn't know whether the authenticator and EAP server are 
co-located or not, so that Server-Id seems like the only thing that the peer 
has to verify server authorization.  The authenticator and server could 
collude in the pass-through or standalone case, and there is really no way 
for the peer to detect this.

Do you have some text to suggest?