eap Mailing List: Re: Questions and comments on draft-cam-winget-eap-fast-00.txt

[Jari Arkko (jari.arkko]

Hi Joe,

Please find some responses inline.

Sorry for not getting back to you sooner on this.

I see that you have also submitted
draft-salowey-tls-ticket-00.txt, presumably to
separate EAP FAST and any possible TLS extensions.
Good!

> > - The protocol is also quite flexible, which is good. I'm somewhat
> >   worried that the protocol leaves too much room for flexibility in
> >   some case, however. For instance, is it really necessary to allow
> >   other mechanisms than EAP-FAST to set up the PAC?
>
>
> [Joe] We have worked with some devices with weak processors that cannot
> perform the provisioning protocol so we wanted to account for variation in
> the way the PAC is delivered. I do think we need to be more specific about
> what is required and recommended on server and client platforms. In any case
> I think it is good to maintain some architectural separation between the PAC
> establishment and usage.

(Given that all cellphones that I have had over the last couple
of years do TLS, I'm not sure the weak processor issue is that
big issue in reality.)

I'm willing to assume that there's a need for a more light weight
provisioning scheme. But what I'm worried about is that
if the PAC delivery is left too open, it will leave too much
room so that someone will end up doing it wrong. You mention
above that you could include some recommendations on the platforms.
Would it be sufficient if you stated that the PAC can also be
configured manually. That would exclude other schemes that would
have potentially surprising system-level security implications.

> [Joe] We are preparing a draft that separates out the extensions so they can
> be discussed with the TLS shared key discussions.

Great!

> > - In some cases there's more room to interpretation and implementation
> >   differences that I would perhaps like. For instance, inclusion of
> >   the EAP header portion of EAP-TLV payloads is only a
> > SHOULD; I'm not
> >   sure I see how the format can differ, shouldn't this be a MUST? 
>
>
> [Joe] Yes this should be more specific, The EAP-TLV within the tunnel MUST
> NOT have an EAP header. 

Ok.

> > - The draft should state more clearly what keying material is
> >   exported from inner methods. The MSK?
>
> [Joe] only the MSK is required from the inner method.

Ok.

> > - It would be good if the draft explicitly required the same authz
> >   checks to be performed when doing fast resume vs. full   
> > authentication. 
>
>
> [Joe] I'm not sure I follow, the authorization done can vary based on a
> number of parameters.  Is there something that you are specifically trying
> to address?

Nothing specific, I just wanted a reminder for the implementor
that authz checks, if any, apply both to full authentication
and fast resume. But it could be obvious.

> > I'm
> >   not sure I understood exactly what can be done with the PAC-Opaque,
> >   can it make servers stateless, or just keep less state?
>
>
> [Joe] The amount of state that the PAC-Opaque allows you to avoid is
> implementation dependant. In a minimal implementation the PAC-Opaque would
> allow you to eliminate storing state for every resumable TLS session on the
> server.  In this case the PAC-Opaque provides the server with a strong key
> to use in protecting an weaker password based exchange such as MSCHAPv2.
> The PAC-Opaque can be used to store more state to optimize authentication
> and authorization as well.  Since the opaque is not understood by the client
> the server can decide how to handle the PAC-Opaque.  

Ok.

--Jari