Sam,

I see you are talking about a different way of using EAP (different then the 
legacy use).

In legacy use, a secure channel is created with the help of the EAP. EAP MSK is 
used for setting it up.

You are talking about the following:
- there's already a secure channel, with integrity and replay protection, and 
even possibly encryption.
- but the end-point is not authenticated yet.
- this is why we execute EAP over it.
- but the EAP keys (MSK) is not used for securing the channel.

I think it's this distinction causing potential differences in other aspects of 
EAP use.

Alper




On Nov 5, 2012, at 5:35 PM, Sam Hartman wrote:

>>>>>> "Alper" == Alper Yegin <[email protected]> writes:
> 
>    Alper> I won't be there either, so here are my comments on Sam's
>    Alper> slides: Slide 5: Please elaborate the pros and cons of
>    Alper> re-auth. There's a reference to some apps replacing session
>    Alper> easily. It'd be good to have a example of that for a better
>    Alper> understanding.
> 
> I'd appreciate help on the proes.
> The big pro that I see is  that  re-auth is necessary  if you need to
> change security parameters and breaking down your session has
> consequences.
> It's obvious to see this in network access.
> 
>    Alper> Slide 6: "Application authorization lifetime". We need to
>    Alper> expand on the meaning of that, or use a more precise
>    Alper> terminology. I If this is about "authorizing the application
>    Alper> client to use the given application protocol", then that
>    Alper> authorization's lifetime is dictated by the MSK
>    Alper> lifetime. It's the use of MSK or its derivative protecting
>    Alper> the application protocol that proves to the server that the
>    Alper> client is authorized. I.e., no key => nothing to prove
>    Alper> authorization with.  
> 
> There are a number of cases where this is not true .
> For example with the GS2 sasl mechanism keying at the TLS layer  is not
> affected by the MSK.
> The EAP authentication is only used for RFC 5056 channel binding.

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to