Subject: [abfab] EAP Applicability discussion

From: Stefan Winter <[email-masked]>
Date: Mon, 05 Nov 2012 14:45:57 +0100

Hi,

since I won't be at the meeting, here are a few thoughts about Sam's
slides regarding the EAP Applicability draft, particularly about

Authorization Lifetime, Slide 6

The original Applicability statement IMHO makes quite clear that
determining the Authorization Lifetime is not a good use of EAP. It
first creates a very short white-list of good uses (Network
*Authentication*, and with the revision Application *authentication*)
and then has a blanket statement blacklist:

"Use of EAP for other purposes, [...], is NOT RECOMMENDED."

One example is given, bulk data transport, but the statement is just as
valid for other examples like ", such as determining authorization
lifetime, "

That statement has served well over the years to repel other uses of EAP
(and in fact seems to be so threatening that abfab found that change of
text is needed to get something new onto the whitelist).

So answering the question brought up by Sam: I do not believe this needs
to be documented. The generic NOT RECOMMENDED statement covers this
adequately.

For the other issues in the slide deck things are less clear; I'll be
interested in the outcomes of the discussion.

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 5 Nov 2012 17:14:41 +0200

I won't be there either, so here are my comments on Sam's slides:

Slide 5: Please elaborate the pros and cons of re-auth. There's a reference to some apps replacing session easily. It'd be good to have a example of that for a better understanding.

Slide 6: "Application authorization lifetime". We need to expand on the meaning of that, or use a more precise terminology. I
If this is about "authorizing the application client to use the given application protocol", then that authorization's lifetime is dictated by the MSK lifetime. It's the use of MSK or its derivative protecting the application protocol that proves to the server that the client is authorized. I.e., no key => nothing to prove authorization with.
If you are talking about the "state created by the use of application protocol" which can exceed the lifetime of the MSK, that's fine. That's more like "application is authorized to create state that can outlive the MSK lifetime". 

On Nov 5, 2012, at 3:45 PM, Stefan Winter wrote:

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Nov 2012 10:35:42 -0500

>>>>> "Alper" == Alper Yegin <[email-masked]> 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.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 6 Nov 2012 10:05:22 +0200

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Nov 2012 07:01:34 -0500

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

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

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

Actually, I'm aware of multiple lower layers that don't work this way.
An easy example to look at is IKEv2.

ABFAB's lower layer supports multiple modes of operation: one in which
MSKs are used to set up a secure channel and one in which endpoints are
authenticated over an existing channel.

--Sam