Subject: [abfab] EAP Applicability: Lifetime of Authorizations

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 09:59:58 -0400

Another issue that has come up in the PCP discussions is  the question
of authorization lifetimes.
Various AAA documents including the EAP keying framework limit the
session lifetime based on what you get back from AAA.
In the case of network access, that's kind of obvious: your ability to
send packets is limited by the lifetime.
There's a lot of discussion of complexity surrounding
pre-authentication, but the general concept is only mildly complex.

It's more complex with applications.
If I go commit some source code, that change will persist well past my
ssh session.

PCP is a NAT/firewall management protocol. It creates NAT mappings among
other things.
There has been some heated debate about whether the lifetime of these
mappings should be dependend on the authentication session.

One argument is that during the authentication session, you are
authorized to  make mapping changes. The server gets to decide how long
those mappings are using whatever policy it likes.
The server can limit things to the authentication session lifetime if it
likes.

Another argument is that the PCP security protocol should place
requirements on this like the AAA keying framework does for network
sessions.

the question of what PCP should do belongs in that WG; I don't want to
discuss it here.

However, I think we should clarify whether EAP or AAA has anything to
say about this.
I think the answer is that AAA has a session lifetime, but what that
means for applications and what persists beyond that session needs to be
decided by those apps.

I'd like to have fairly clear text that  this is an application decision
and that EAP and AAA are not trying to define the extent of a session or
lifetime for applications.
Other people involved in the PCP discussion may disagree with me and
prefer that EAP/AAA define this for apps.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Fri, 19 Oct 2012 16:10:15 +0200

Hi,

> prefer that EAP/AAA define this for apps.

It sounds to me like the sequence of events here should better be: you
and the other people in PCP come to an agreement which of the two
approaches should be taken and *then* one has to think whether a
corresponding update to either section 1.3 or any other part of RFC3748
is necessary.

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: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 10:40:03 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi,
    >> I'd like to have fairly clear text that this is an application
    >> decision and that EAP and AAA are not trying to define the extent
    >> of a session or lifetime for applications.  Other people involved
    >> in the PCP discussion may disagree with me and prefer that
    >> EAP/AAA define this for apps.

    Stefan> It sounds to me like the sequence of events here should
    Stefan> better be: you and the other people in PCP come to an
    Stefan> agreement which of the two approaches should be taken and
    Stefan> *then* one has to think whether a corresponding update to
    Stefan> either section 1.3 or any other part of RFC3748 is
    Stefan> necessary.

I'm confused by your message because I don't understand how PCP can make
the decision without understanding the EAP requirements.

If EAP is going to make requirements of PCP, then either PCP needs to
meet those requirements or not use EAP.
so, I think we need to understand the general requirements to understand
what our options are in PCP.

So, would you be willing to explain why you believe PCP should decide on
its requirements first and how you see that interacting with a later
general discussion?

--Sam

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 19 Oct 2012 16:46:35 +0200

On Oct 19, 2012, at 3:59 PM, Sam Hartman <[email-masked]> wrote:

Sam,

The way I look at it is that you talk about two different types of authorisations, one where the AAA-server says "for the following x seconds my vouch for the fact that Sam has successfully authenticated and is associated with the following attributes" and the other where the resource owner decides what should happen once that assertion is not valid anymore. I don't believe it is the business of the AAA-server to say what the resource owner must do. If someone has configured my firewalls perfectly and now leaves for another company, I do want to make sure he can not mess with my configs anymore, but I definitely don;t want to have to redo all my configuration. At the same time, I can also imagine cases where you do want to roll back actions someone undertook. So all in all, this is application logic that I don't think we should try to specify. And indeed, for one particular application, like network access, it may make perfect sense to specify the behaviour explicitly.

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 10:49:31 -0400

>>>>> "Klaas" == Klaas Wierenga <[email-masked]> writes:

    Klaas> On Oct 19, 2012, at 3:59 PM, Sam Hartman <[email-masked]> wrote:

Sam,

    Klaas> The way I look at it is that you talk about two different
    Klaas> types of authorisations, one where the AAA-server says "for
    Klaas> the following x seconds my vouch for the fact that Sam has
    Klaas> successfully authenticated and is associated with the
    Klaas> following attributes" and the other where the resource owner
    Klaas> decides what should happen once that assertion is not valid
    Klaas> anymore. I don't believe it is the business of the AAA-server
    Klaas> to say what the resource owner must do. If someone has
    Klaas> configured my firewalls perfectly and now leaves for another
    Klaas> company, I do want to make sure he can not mess with my
    Klaas> configs anymore, but I definitely don;t want to have to redo
    Klaas> all my configuration. At the same time, I can also imagine
    Klaas> cases where you do want to roll back actions someone
    Klaas> undertook. So all in all, this is application logic that I
    Klaas> don't think we should try to specify. And indeed, for one
    Klaas> particular application, like network access, it may make
    Klaas> perfect sense to specify the behaviour explicitly.

+1
This is really well stated.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 19 Oct 2012 17:22:50 +0200

Hi,

> what our options are in PCP.

EAP does not make requirements for PCP in this case; the question is
left open in the RFC.

That is highly understandable, IMHO, because EAP is the Extensible
Authentication protocol; *authorisation* lifetime is not something
that's naturally covered.

> its requirements first and how you see that interacting with a later

You described two courses of action: PCP can either make applications
decide on the authorization lifetime on their own, or it can request
that this lifetime information is derived from EAP.

We agree that the question which course to take is PCP's decision alone.
The text in the EAP RFC seems to allow for both; there is lifetime
information that can either be made use of, or can be ignored. Given
that the information is meant for authentication, it may not be the best
idea to overload it and use it for authorisation information; but since
signalling authorisation is out of scope for EAP, that doesn't
necessarily need to be included in EAP applicability text.

One could argue that the EAP Applicability Statement is actually quite
clear: it doesn't mention the word authorization.

So, probably, whichever of the two courses the PCP wg might favour,
chances are good that none of the two require changes to the
applicability statement. If the wg thinks that they need a specific use
of EAP and they are unsure whether their specific need is covered or
not, they can try to sort that out at that point. I would worry about
clarifying wording when that has happened.

If your intent was to add a "non-applicability" statement like: EAP
doesn't care about your authorisation lifetime, then yes, such a
statement could be made, but isn't it implicit that everything that is
not mentioned as being applicable is not applicable? EAP also doesn't do
accounting nor coffee; maybe that needs to be stated, too.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 11:40:51 -0400

Stefan> Hi,
    >> I'm confused by your message because I don't understand how PCP
    >> can make the decision without understanding the EAP requirements.
    >> 
    >> If EAP is going to make requirements of PCP, then either PCP
    >> needs to meet those requirements or not use EAP.  so, I think we
    >> need to understand the general requirements to understand what
    >> our options are in PCP.

    Stefan> EAP does not make requirements for PCP in this case; the
    Stefan> question is left open in the RFC.

    Stefan> That is highly understandable, IMHO, because EAP is the
    Stefan> Extensible Authentication protocol; *authorisation* lifetime
    Stefan> is not something that's naturally covered.

Right. And I'm asking to point  out that this is not covered in the
applicability statement.
I think Klaas does a great job of explaining the situation and I'd like
to work on adapting his message for text.

    >> So, would you be willing to explain why you believe PCP should
    >> decide on its requirements first and how you see that interacting
    >> with a later general discussion?

    Stefan> You described two courses of action: PCP can either make
    Stefan> applications decide on the authorization lifetime on their
    Stefan> own, or it can request that this lifetime information is
    Stefan> derived from EAP.

Thanks for helping explain.
I now understand my confusion and believe it was because I was unclear
in my message.
In my mind PCP was the application.
I was arguing that here in ABFAB we have two courses of action:

1) Say that applications need to figure out authorization lifetime on
their own.
I favor this.

2) Say that as part of making EAP applicable to application
authentication, we make requirements for all applications using EAP on
authorization lifetime.
I prefer the first option.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Fri, 19 Oct 2012 15:57:11 +0000

+1

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Oct 2012 02:25:06 +0900

I think the two options you provided below are two extremes.  It is too 
restrictive
to have a requirement on one of the two extremes.  I can think of an 
application that can choose
to follow AAA-associatied authorization lifetime or use its own 
(AAA-independent)
lifetime depending on use case.

Having said that I don't think we need to change EAP applicability text 
on this matter.

Thanks,
Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 13:35:32 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> I think the two options you provided below are two
    Yoshihiro> extremes.  It is too restrictive to have a requirement on
    Yoshihiro> one of the two extremes.  I can think of an application
    Yoshihiro> that can choose to follow AAA-associatied authorization
    Yoshihiro> lifetime or use its own (AAA-independent) lifetime
    Yoshihiro> depending on use case.

That's well within what I mean by option 1--leave it up to the
application.
One reasonable thing for applications to do  in some usecases  would be
to depend on AAA.

Would you be willing to review text to make sure we don't exclude this
sort of thing?

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 20 Oct 2012 02:43:57 +0900

> One reasonable thing for applications to do  in some usecases  would be

OK.

> Would you be willing to review text to make sure we don't exclude this

I think "less is more" is the best stragegy here, i.e., no need to add text.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Oct 2012 14:09:11 -0400

OK.
If we're all agreed that it is clear I'm fine adding no text.
However, Alper claimed that  the EAP keying framework requires something
close to option 2.

It sounds like that's not my interpretation or your interpretation.
If we think others might read things the same as Alper, then I think we
should clarify things in the applicability statement.
If we think that sort of reading is unlikely, I'm fine saying nothing.

--Sam

---

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Oct 2012 13:56:15 +0300

Like I said over PCP ML,
the AAA message that delivers EAP Success and MSK also delivers the authorized lifetime.
This is one of the tasks of the Authentication-"Authorization"-Accounting (AAA) server. To tell the NAS for how long the authenticated entity is authorized to access the requested service.
The session lifetime can be set to this received value, or a smaller value by the NAS and the authenticated client -- hopefully in a coordinated way.
The MSK lifetime is set to this value as well.

Now, if someone tells me the NAS can set the lifetime value to anything irrespective of the lifetime received from the AAA, then I say he's using a centralized AA (authentication and accounting) server with distributed A (Authorization). An interesting case, not typical but doable. Someone may have a very special reason to do that.

Regarding the application state that is created within the authorized application session, yes I understand and agree that it may survive beyond the authorized session. But that's very application specific. We need to discuss that in the scope of specific applications.

Alper

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Oct 2012 13:01:06 +0200

> Now, if someone tells me the NAS can set the lifetime value to anything irrespective of the lifetime received from the AAA, then I say he's using a centralized AA (authentication and accounting) se…

  NASes have always had "creative" interpretations of authorization
policies coming from an AAA servers.  So this behavior is well within
the traditional AAA.

> Regarding the application state that is created within the authorized application session, yes I understand and agree that it may survive beyond the authorized session. But that's very application…

  I agree.

  I would phrase the difference as being either the ability to *do*
something, or the ability to *have* something.  Items like "session
timeout" control the ability to have a session.  Once the session is
over, the ability goes away.  Other items could be allowed to continue,
even after the session has been finished.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 29 Oct 2012 03:29:09 +0000

It seems that most of this discussion has to do with application  authorization and AAA and not with EAP.   As Alan points out there are several different ways session lifetime can be dealt with in current deployments ome of which put more control int he AAA and others more in the NAS.    Its not clear to me that this belongs in an applicability statement.  

Joe