Subject: [Pana] EAP-Request/Identity & PANA-Start-Request

From: [email-masked]
Date: Fri, 10 Oct 2003 15:53:06 +0300

PANA folks,

We have PANA-Start-Request/Answer messgae pair carrying Cookie.
Then we have the first PANA-Auth-Request/Answer message pair 
carrying EAP-Request/Identity and EAP-Response/Identity. The 
EAP-Request/Identity is generated in the PAA/NAS, because/which 
at that point doesn't know the realm for the user. EAP header 
also contains the identifier field which is somewhat analoguous 
to PANA cookie. Why not to put the first EAP payload AVP into 
the PANA-Start-Request message? This doesn't bring any new 
requirements for the PAA to create state information, because 
the EAP header identifier field can act similarly to PANA cookie 
AVP... or in the extreme we could drop the cookie AVP and use 
the EAP identifier field as the "cookie".

Let me hear your comments.

Br,
- Dan

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

---

From: [email-masked]
Date: Mon, 13 Oct 2003 14:58:50 +0300

Hi Yoshihiro,

Your arguments are not exactly valid. 

We could also say that PaC sends always EAP-Payload AVP 
that contains EAP-Response/Identity in the PANA-Start-Answer 
message. I.e. no EAP-Request is necessarily needed from PAA.

PAA can itself create the EAP-Request thus the authenticator 
is not involved.

Otherwise PaC needs to send it's identity to the PAA out 
of the EAP so that PAA/NAS can contact the right authenticator.

- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 10 October, 2003 18:35
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Pana] EAP-Request/Identity & PANA-Start-Request
>
>
> On Fri, Oct 10, 2003 at 03:53:06PM +0300,
> [email-masked] wrote:
> > PANA folks,
> >
> There are two things we need to consider here:
>
> o The first EAP Request sent by the EAP authenticator is not always
>   EAP-Request/Identity, i.e., the use of EAP-Request/Identity
> is optional when
>   the client identity can be obtained by some other means.
>
> o EAP state machine (draft-ietf-eap-statemachines-00.{txt,ps}) does
>   not allow an EAP authenticator to be stateless when sending
> the first EAP Request.
>
> So in general PAA cannot be stateless when sending a
> PANA-Start-Request
> with piggybacking an EAP Request.
>
> Yoshihiro Ohba
>
>
>
> >

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 14 Oct 2003 10:09:51 +0200

hi dan, 

there are several issues there: 

first, i like the idea of keeping the number of roundtrips at a minimum. i
think that it would be possible to have an option for submitting the
EAP-Request/Identity message immediately with the PANA-Start-Request by the
PAA after receiving the PANA-PAA-Discover message. it could be left to the
paa to skip the denial of service protection and to immediately start with
eap authentication (similar to the optional dos protection in ikev2). 

note that the discovery mechanisms is optional and therefore the
PANA-Auth-Request / PANA-Auth-Answer must still be able to perform the eap
identity exchange. 

yet another issue is whether to reuse something inside the eap header (e.g.
some identifier) as a cookie. i am not sure about this approach. 

ciao
hannes

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 10, 2003 2:53 PM
> To: [email-masked]
> Subject: [Pana] EAP-Request/Identity & PANA-Start-Request
> 
> 
> PANA folks,
>

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 14 Oct 2003 10:09:51 +0200

hi dan, 

ciao
hannes

---

From: [email-masked]
Date: Tue, 14 Oct 2003 14:01:02 +0300

> Sent: 13 October, 2003 19:25
> Cc: [email-masked]; [email-masked]
> Hi Dan,
> On Mon, Oct 13, 2003 at 02:58:50PM +0300,
> EAP does not allow EAP peers to unsolicitedly send EAP-Response.

That is not a problem. The lower layer can generate an EAP-Request. 
Or the PAA can send it.

> The current EAP authenticator state machine on the NAS does not allow
> lower-layer entity (e.g., PAA) to create an EAP Request on behalf of
> the authenticator.

That's fine, but what if the authenticator is on the AAA backend 
and NAS acts only as a pass-through.

I'm not coming up this by myself. See dratf-ietf-aaa-eap-02.txt 
section 2.2., the "preferred way" (second figure).

Another alternative is that the client sends User-Name or User-Realm 
AVP in PANA-Start-Answer from PaC to PAA. But I think that this 
"preferred way" is good to have. 

Do you see any problems in this? If there are, we have to notify the 
draft-ietf-aaa-eap-02.txt authors too.

- Dan

> In some EAP environment where MAC address is used as a client
> identifier, the identifier can be effectively obtained from the MAC
> header that carries PANA message without using EAP-Identity exchange.
>
> >
> > - Dan
>
> Yoshihiro Ohba
>
> >
> > > o EAP state machine
> (draft-ietf-eap-statemachines-00.{txt,ps}) does

---

From: [email-masked]
Date: Wed, 15 Oct 2003 11:47:18 +0300

Hi Yoshi,

See below.

> Sent: 14 October, 2003 19:18
> On Tue, Oct 14, 2003 at 02:01:02PM +0300,
> The passthrough authenticator behavior described in
> dratf-ietf-aaa-eap-02.txt is explicitly supported in the EAP state
> machines draft (draft-ietf-eap-statemachines-00.txt), but when this
> happens, the initial EAP Request/Identity is always generated *at EAP
> layer*, not at PANA layer. So the proposed approach will not work for
> an implementation that is based on
> draft-ietf-eap-statemachines-00.txt.

Yes, I meant that the EAP layer is kicked to do it. I mixed EAP backend 
authenticator and passthrough authenticator. It's a bit misleading to use 
the same term for both entities.

> I think the "preferred way" is automatically supported in the currrent
> combination of PANA and EAP, i.e., the passthrough EAP authenticator
> (that is co-located with PAA) generates the initial EAP
> Request/Identity and passes it PAA, which then puts the message in a
> PANA message and forwards it to the PaC. 

Ok. 

>
> The issue we are discussing is: which PANA message should carry the
> initial EAP Request/Identity and here is my suggestion: 
>
>   "When a Cookie-AVP is carried in a PANA-Start-Request message, the
>   initial EAP Request MUST NOT be carried in the PANA-Start-Request
>   message in order for the PAA to be stateful.

I don't think that the Cookie makes PAA necessarily stateful. PAA could
use a timestamp and a hash of PaC's address, encrypt that with a secret 
key and use it as a cookie. When PAA checks the cookie, it decrypts it 
and checks the timestamp and address hash. No state required. I'm not a 
cookie expert, though.

>
>   When a Cookie-AVP is not carried in a PANA-Start-Request message,
>   the PAA does not need to be stateful.  In this case, the initial EAP
>   Request message MAY be carried in the PANA-Start-Request message.
>   If the initial EAP Request message is carried in the
>   PANA-Start-Request message, an EAP Response message MUST be carried
>   in the PANA-Start-Answer message returned to the PAA.
>  
>   In any case, PANA MUST NOT generate an EAP message on behalf of
>   EAP peer or EAP authenticator."

Just for clarification and for easier understanding what about: 
   "In any case, PANA MUST NOT generate an EAP message on behalf of
    EAP peer or EAP (passthrough) authenticator."

>
> I think this allows saving one round trip when PAA does not need to be
> stateless.

Ok, but I don't fully agree about the separation of Cookie and EAP-Request. 
See the comment above.

I guess you meant stateful?

- Dan

> What do you think?

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 15 Oct 2003 10:57:12 +0200

hi yoshi, 
hi dan, 

i haven't seen a response to the proposal for making the denial of service
protection optional. 

ciao
hannes

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Tuesday, October 14, 2003 6:18 PM
> To: [email-masked]

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 15 Oct 2003 10:57:12 +0200

hi yoshi, 
hi dan, 

ciao
hannes

---

From: [email-masked]
Date: Thu, 16 Oct 2003 11:11:58 +0300

Hi Yoshi,

I don't know the EAP state machines, but I guess they are 
intepretations of the EAP protocol specification. 

You said that EAP-Request/Response Identity message exchange 
is optional. This seems to imply that the EAP authenticator
does not have to be stateful during identity "discovery"?
How does the authenticator skip the identity request/response 
part when the identity is known outside EAP already?

This is why I can't see your separation to stateless or 
stateful.

- Dan

> Sent: 15 October, 2003 19:39
> On Wed, Oct 15, 2003 at 11:47:18AM +0300,
> Sorry, that is a typo, "stateful" should read "stateless".
>
> >
> > >
> This is the same typo, "stateful" should read "stateless".
>
> OK.
> After fixing the typo, I guess we are in agreement.
>
> Yoshihiro Ohba
>
>