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

From: [email-masked]
Date: Thu, 16 Oct 2003 10:39:53 +0300

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 15 October, 2003 19:24
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Pana] [issue19] Result-Code AVP values?
>
>
> On Wed, Oct 15, 2003 at 11:06:17AM +0300,
> [email-masked] wrote:
> > 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).
>
> 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.

How can EAP authenticator generate an error if it only passes the message 
for the AAA routing process and the error comes from the AAA routing?

[On the other thread we are discussing about using ISP and NAP identifiers. 
I think this problem relates to this discussion. We may need a similar 
error code there too (i.e. "unknown ISP/NAP identifier/realm").]

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

How does the passthrough authenticator (NAS) know if the Identity is 
not correct when the syntax is perfect? Even the PAA/NAS may not know 
this but forwards the message to the AAA proxy/relay etc. Anyway, if the 
realm really isn't served, then the NAS/PAA receives this kind of error 
code. What happens then?

>
> (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
> > the network side?
>
> 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.

PANA and AAA are next to each other (or even glued together.. "upper 
layer PANA" and "lower layer PANA") and EAP is above them. Why to pass 
errors that the EAP doesn't know to the EAP? Instead AAA errors can 
be passed to PANA when necessary. EAP has limitations.

- Dan

>
> Yoshihiro Ohba
>
>
> >
> > - 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: Thu, 16 Oct 2003 09:12:49 -0700

I believe the issues you have addressed below are for Diameter EAP
application draft and EAP state machines.  As far as I know, when an
AAA message routing error occurs, the EAP authenticator on the NAS
will not receive any EAP message or a signal from AAA.  Instead, it
relies on a timeout event generated by itself ("aaaTimeout" variable
is defined in the EAP full authenticator state machine).  When the
timeout occurs, the EAP authenticator enters a final state
TIMEOUT_FAILURE2 with setting eapTimout = TRUE but without generating
an EAP Failure (This is a mandatory behavior defined in RFC3579).  

So the EAP authenticator on the NAS may not be able to generate any
EAP message when the AAA message routing error occurs.  

I would suggest creating a new PANA issue on how to handle the case in
which an EAP authenticator on the NAS fails to authenticate an EAP
peer without generating an EAP message.  We can continue the
discussion on whether AAA error needs to be leaked to PANA in the new
issue.

Can we close issue19?

Yoshihiro Ohba

> not correct when the syntax is perfect? Even the PAA/NAS may not know 
\> this but forwards the message to the AAA proxy/relay etc. Anyway, if the

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Oct 2003 09:12:49 -0700

Can we close issue19?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 12:08:54 -0700

> discussion on whether AAA error needs to be leaked to PANA in the new

This is a good approach. I agree we should close issue 19, and open a more
specific one for this case.

Alper

> ¥> this but forwards the message to the AAA proxy/relay etc. Anyway, if the

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Oct 2003 12:08:54 -0700

Alper