Subject: [Pana] [issue34] Behaviour with NAP and ISP (two EAP authentications).

From: [email-masked]
Date: Wed, 1 Oct 2003 13:53:00 +0300

New submission from Dan Forsberg <[email-masked]>:

How does Session-Lifetime (or Session-Timeout) realate to NAP and ISP
authentications? When this lifetime expires PaC should probably
reauthenticate to NAP and ISP? 

Clarification needed into the draft also for the case of session
terminateion. Does PaC or PAA terminate the part of the session that
relates to the ISP or NAP or both.

Would it be simpler to use PANA sessions with one EAP method only,
instead of two serial EAP methods in one session. Or should there be one
master session (NAP) and then subsessions (for ISPs). When the master
session is terminated, the subsessions are also terminated. PaC and PAA
can also terminate subsessions. Reauthentication should happen for all
the sessions because of independent EAP methods.

- Dan

----------
category: Technical
document: draft-ietf-pana-pana-xx.txt
messages: 105
nosy: dforsber
priority: Must Fix
status: No Discussion
title: Behaviour with NAP and ISP (two EAP authentications).
________________________________________________
PANA Issues <[email-masked]>
http://danforsberg.info:8080/pana-issues/issue34
________________________________________________

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Oct 2003 09:03:16 -0700

This is an interesting issue.

Basically there are pros and cons as to whether using a distinct PANA
session for each of two EAP authentication or using a single PANA
session for two EAP authentications.

As you mentioned, using a distinct PANA session for each of NAP and
ISP authentications will make it easier to handle different session
lifetimes for NAP and ISP.  However, there would be the
following cons in this approach:

o Which PANA SA should be used for bootstrapping IPsec and/or DHCP
  authentication?

o What happens if the PANA session from which IPsec and/or DHCP
  authentication are bootstrapped is terminated while the other PANA
  session still remains established.

Especially the latter issue would be more difficult to solve and I
don't recommend this approach.

Using a singel PANA session for both NAP and ISP authentications does
not have above the issues because there is only one PANA SA (and we
already decided to use the MSK of the first successul EAP
authentication with key derivation to derive the PANA SA).  This also
implies that when a PANA session is terminated, both NAP and ISP
authorizations will be removed.  On the other hand, consideration is
needed for this approach to handle different session lifetimes for NAP
and ISP, as you also mentioned below.  One solution to deal with this
is to perform both EAP-based re-authentications for both NAP and ISP
with using the minimum value of the NAP and ISP session lifetimes as
the PANA session lifetime (though this is not efficient when the
difference between the NAP and ISP session lifetimes are large.)

What do you think?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Oct 2003 09:03:16 -0700

What do you think?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 02 Oct 2003 11:53:57 -0700

This is what we said in the requirements draft:

   Determining the authorization
   parameters as a result of two separate authentications is an
   operational issue and therefore it is outside the scope of PANA.

I think from PANA perspective, it is sufficient to enable two rounds of
authentication. But other than that, we should let the NAS mold NAP and ISP
authentication into a single "PANA session". How exactly this be done should
not be the concern of the base pana protocol. And once there is a session,
neither PAA nor PaC would see "ISP session" or "NAP session", it is just a
"combined session".

Cost (complexity) of separating NAP and ISP authentication beyond what we
already provide seems higher than the benefits, imo.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 02 Oct 2003 11:53:57 -0700

Alper