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

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

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 13 October, 2003 19:25
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Pana] EAP-Request/Identity & PANA-Start-Request
>
>
> Hi Dan,
>
> On Mon, Oct 13, 2003 at 02:58:50PM +0300,
> [email-masked] wrote:
> > 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.
>
> 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.

> >
> > PAA can itself create the EAP-Request thus the authenticator
> > is not involved.
>
> 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

> >
> > Otherwise PaC needs to send it's identity to the PAA out
> > of the EAP so that PAA/NAS can contact the right authenticator.
>
> 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
>
> >
> > > -----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,
> > > >
> > > > 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".
> > >
> > > 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
> > >
> > >
> > >
> > > >
> > > > Let me hear your comments.
> > > >
> > > > Br,
> > > > - Dan
> > > >
> > > > _______________________________________________
> > > > Pana mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pana
> > >
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 09:18:14 -0700

Hi Dan,

> section 2.2., the "preferred way" (second figure).

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.

> "preferred way" is good to have. 

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.  

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.

  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."

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

What do you think?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 14 Oct 2003 09:18:14 -0700

Hi Dan,

  

What do you think?

Yoshihiro Ohba