Subject: PANA protocol specification version 00 here

From: Alper Yegin <[email-masked]>
Date: Mon, 10 Mar 2003 12:24:25 -0800

Hello,

PANA design team has concluded its work and produced the version 00
of the PANA protocol specification. Since we missed the deadline, it won't
be posted on the IETF repository until after the SF meeting.

Draft: http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-00.txt
Mailing list archive: http://danforsberg.info/pipermail/pana-dt/

Please see the PANA supplemental web page,
http://www.toshiba.com/tari/pana/pana.htm, for more information.

Please read the draft and provide comments before the IETF meeting.
The solution discussions at the meeting will be centered around this draft,
hence it is part of the mandatory reading.

- chairs

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 11 Mar 2003 14:33:52 +0100

> hence it is part of the mandatory reading.

Hi,

 I've just read the draft and I just wanted to know
why the PaC doesn't have any way to "authenticate" the 
PAA ?. 

Aren't we vulnerable to a MiTM if it can't be sure
to whom is giving authentication information ?

thanks

[email-masked]

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 11 Mar 2003 17:25:30 +0100

Hi,

 If a PaC do a handover and change of AP (e.G. in case of 802.11b)
it could change of PAA and EP. In such a case the new PAA will
try to authenticate him whereas it has already been authenticated
to the previous PAA. MAybe it could be a benefit to add the abality
to the PaC to inform the new PAA of the previous PAA. As such the 
new PAA could retrieve information from previous PAA without 
reauthenticate the PaC.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Mar 2003 21:40:50 +0100

hi

we have shortly discussed mobility issues within pana. there are still open
issues there.

> new PAA could retrieve information from previous PAA without

there are various issues here. most of them are associated with performance
improvements.

- type of mobility: micro-/macro-mobility
i guess we talk about intra-domain mobility only.

- type of authentication performed after the handover

a) we could avoid interaction with aaah.
b) we could avoid interaction with aaal.

for (a) people have suggested to case session keys at the local aaa server.
this provides performance improvement by skipping a inter-domain
communciation to the home aaa server.

for (b) an interaction with a intra-domain mobility protocol is possible.
the protocol machinery is very simple. further work on this topic requires
that we make progress on the pana protocol first.

thank you for your comment.

ciao
hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Mar 2003 21:40:56 +0100

hi julien,

> why the PaC doesn't have any way to "authenticate" the

eap does not describe where the other end point is. it could also be the
paa.
even if the eap end point is the aaal or the aaah then the trust
relationship between them allows to establish a financial settlement between
the two networks. in some cases it is not even desired to authenticate the
end host to the access network itself - think of user identity
confidentiality. with user id conf. the pac authenticates himself to the
home aaa server using the aaa infrastructure and the home network of the pac
provides some assurance for the financial settlement.

furthermore, since you establish a pana security association (which requires
that the session key is transferred from the eap end point to the paa) you
actually provide key confirmation.

i have to mention that we discussed two possible approaches to provide
network access authentication. you can find our discussions at a separate
mailing list: http://danforsberg.info/mailman/listinfo/pana-dt
these issues have, however, been discussed with a different purpose.

> to whom is giving authentication information ?

actually, i would say no.

however, the answer is not that simple.

to some extend it depends on your eap method. if you provide a user
name/password to a network then this network might misuse your credentials.
however, even with pac-to-paa authentication the end host does not get this
gurantee.

for the pana protocol we made the working assumption that we don't want to
fix authentication and key exchange protocols. this is left to the
responsibility to those entities using the eap method (e.g. to the home
network provider where the user is subscribed). for further discussion on
some of these topics take a look at some discussion items found at:
http://www.tschofenig.com/pana/

was i able to provide you an answer?

ciao
hannes

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 12 Mar 2003 12:37:39 +0100

> i guess we talk about intra-domain mobility only.

exactly, in inter-domain mobility I guess that we need to contact
aaah.

> communciation to the home aaa server.
I agree
 
> that we make progress on the pana protocol first.

ok, basically, I thought that it could be a flag in the PANA_start from the PaC
indicating that it has been previously authenticated  and information
permitting to the PAA to be sure of this. Sure there are problems 
concerning EP configuration, session key etc... and what information the PaC
must furnish.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Mar 2003 15:04:47 -0800

> to whom is giving authentication information ?

This is a matter of picking the right EAP authentication method.
PANA carries any EAP method, hence does not impose any limitations here.

Choice of EAP method is an operational decision. Depending on the
environment PaC and PAAs are operating, appropriate authentication method
should be used. 

alper