Subject: RE: [Pana] [issue19] Result-Code AVP values?

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

I don't understand your arguments.

PANA_REALM_NOT_SERVED is seen as an error code (see the issue19), not
an authentication result code. No authentication can take place because 
of this error.

This has nothing to do with EAP or? The NAS/PAA can't route the AAA
message because it can't find the routing info for the realm. EAP is 
just carried in the AAA message (EAP-Payload AVP).

Do you think that this result code reveals too much for the PaC about 
the network side?

- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 14 October, 2003 21:03
> To: Alper Yegin
> Cc: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: [Pana] [issue19] Result-Code AVP values?
>
>
> There are already three authentication results defined, i.e.,
> PANA_SUCCESS, PANA_AUTHENTICATION_REJECTED and
> PANA_AUTHORIZATION_REJECTED.  Defining a more detailed result code
> PANA_REALM_NOT_SERVED seems to be a bit inconsistent in design with
> those three fundamental results.
>
> In addition, the EAP state machine draft does not have an interface to
> AAA to obtain detailed error information like REALM_NOT_SERVED, and
> thus in actual implementations it is likely that
> PANA_AUTHENTICATION_REJECTED is used instead of PANA_REALM_NOT_SERVED.
>
> So, my opinion is we don't need to define PANA_REALM_NOT_SERVED.
>
> Yoshihiro Ohba
>
>
> On Mon, Oct 13, 2003 at 10:54:03PM -0700, Alper Yegin wrote:
> > > In PANA we retransmit requests because we want to have reliable
> > > transport. So, the case where the authenticator retransmits the
> > > EAP-Request/Identity is interpreted differently in PANA layer
> > > (retransmissions for reliability).
> > >
> > > The case of Notification Request is usable, but what does
> > > "invalid authentication attempt" mean? Can we interpret it such
> > > a way that it means "typo in the identity, user part" or "user
> > > not recognized" or "realm not served"..
> >
> > Good points, but that does not mean they are problems for
> PANA to solve.
> >
> > Generally I'm concerned about leaking EAP-layer events or
> actions into PANA.
> > But I think in this case, this is more of mapping an EAP lower-layer
> > (Diameter) event to PANA. While I wouldn't simply import
> all such events
> > from one to another, I think this one might be useful and
> not disruptive. On
> > the other hand, this error message is different from all
> the others. Those
> > are all PANA-specific.
> >
> > Hmmm... Does anyone else care to comment on this?
> >
> > Alper
> >
> >
> > >
> > > A result code in PANA for this (borrowed from Diameter) is clear
> > > and works if the authenticator implementation doesn't support
> > > this MAY part of the EAP doc.
> > >
> > > - Dan
> > >
> > >
> > >> -----Original Message-----
> > >> From: ext Alper Yegin [mailto:[email-masked]]
> > >> Sent: 07 October, 2003 20:55
> > >> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> > >> Subject: Re: [Pana] [issue19] Result-Code AVP values?
> > >>
> > >>
> > >>>> I think this is also an EAP question. What would be the EAP
> > >>>> behavior when
> > >>>> the NAS cannot recognize the EAP client identifier?
> > >>
> > >> I think this case would be handled by the following text from
> > >> the EAP spec:
> > >>
> > >>          Implementation Note: The peer MAY obtain the
> > >> Identity via user
> > >>          input.  It is suggested that the authenticator retry the
> > >>          Identity Request in the case of an invalid Identity or
> > >>          authentication failure to allow for potential typos
> > >> on the part
> > >>          of the user.  It is suggested that the Identity
> Request be
> > >>          retried a minimum of 3 times before terminating the
> > >>          authentication.  The Notification Request MAY be used to
> > >>          indicate an invalid authentication attempt prior to
> > >>          transmitting a new Identity Request
> (optionally, the failure
> > >>          MAY be indicated within the message of the new
> > >> Identity Request
> > >>          itself).
> > >>
> > >> ... And finally I think the EAP authenticator would send a
> > >> Failure message.
> > >>
> > >> Alper
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> > _______________________________________________
> > 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:23:30 -0700

> just carried in the AAA message (EAP-Payload AVP).

OK.  I see what you mean.

It would depend on the behavior of of the EAP authenticator on the NAS
when the AAA message routing error happens.

If the authenticator generate an EAP Failure, the result code should
contain an authentication result.

If the authenticator generates a new EAP Request/Identity to give 
the EAP peer another chance to send a correct identity and 
no result code will be included.

(There would be another possibility: the authenticator retransmits the
initial EAP Request/Identity, but this will not work because the EAP
peer will retransmit the old EAP Response/Identity which contains the
old realm that caused the AAA message routing error.)

I don't see a case where a status code of a protocol error class 
is returned in the above scenarios.

> Do you think that this result code reveals too much for the PaC about 

I believe error handling at PAA would be complicated if AAA errors are
revealed to PANA.  PAA should just interface to EAP, not to AAA.

Yoshihiro Ohba

---

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

OK.  I see what you mean.

Yoshihiro Ohba