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

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

Hi Yoshi,

See below.

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

> >
> > 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.
>
> 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?
>
> Yoshihiro Ohba
>
> >
> > 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
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Oct 2003 09:39:03 -0700

Hi Dan,

> and checks the timestamp and address hash. No state required. I'm not a 

Sorry, that is a typo, "stateful" should read "stateless".

> >   the PAA does not need to be stateful.  In this case, the initial EAP

This is the same typo, "stateful" should read "stateless".

>     EAP peer or EAP (passthrough) authenticator."

OK.

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

After fixing the typo, I guess we are in agreement.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Oct 2003 09:39:03 -0700

Hi Dan,

OK.

Yoshihiro Ohba