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

From: [email-masked]
Date: Thu, 2 Oct 2003 10:28:50 +0300

Dan Forsberg <[email-masked]> added the comment:

- Removed error code section separation.
- Removed PANA_TOO_BUSY.
- Clarified PANA_UNABLE_TO_DELIVER.
-------------------------

9.4.7 Result-Code AVP 
 
   The Result-Code AVP is defined in [DIAMETER].  Here are Result-Code
   AVP values taken from [DIAMETER] and adapted for PANA.

9.4.7.1.  Authentication Results Codes

   These result code values inform the PaC about the EAP
   authentication method success or failure.

         PANA_SUCCESS                            2001
            The EAP method authentication was succesfull
            (EAP-Success).

         PANA_AUTHENTICATION_REJECTED            4001
            The authentication process for the client failed
            (EAP-Failure).

         PANA_AUTHORIZATION_REJECTED             5003
             A request was received for which the client could not be
             authorized.  This error could occur if the service
             requested is not permitted to the client.

9.4.7.2.  Protocol Error Result Codes
   
   Protocol error result code values.

         PANA_MESSAGE_UNSUPPORTED                3001
            Error code from PAA to PaC or from PaC to PAA.  Message
            type not recognized or supported.

         PANA_UNABLE_TO_DELIVER                  3002
            Error code from PAA to PaC.  PAA was unable to deliver the
            EAP payload to the authentication server.

         PANA_REALM_NOT_SERVED                   3003
            Error code from PAA to PaC.  The network doesn't recognize
            the realm.

         PANA_INVALID_HDR_BITS                   3008
            Error code from PAA to PaC or from PaC to PAA.  A message
            was received whose bits in the PANA header were either set
            to an invalid combination, or to a value that is
            inconsistent with the message type's definition.

         PANA_INVALID_AVP_BITS                   3009
            Error code from PAA to PaC or from PaC to PAA.  A message
            was received that included an AVP whose flag bits are set
            to an unrecognized value, or that is inconsistent with the
            AVP's definition.

         PANA_AVP_UNSUPPORTED                    5001
            Error code from PAA to PaC or from PaC to PAA.  The
            received message contained an AVP that is not recognized
            or supported and was marked with the Mandatory bit.  A
            PANA message with this error MUST contain one or more
            Failed-AVP AVP containing the AVPs that caused the
            failure.

         PANA_UNKNOWN_SESSION_ID                 5002
            Error code from PAA to PaC or from PaC to PAA.  The
            message contained an unknown Session-Id.  PAA MUST NOT
            send this error result code value to PaC if PaC sent an
            unknown Session-Id in the PANA-Start-Answer message
            (session resumption).

         PANA_INVALID_AVP_VALUE                  5004
            Error code from PAA to PaC or from PaC to PAA.  The
            message contained an AVP with an invalid value in its data
            portion.  A PANA message indicating this error MUST
            include the offending AVPs within a Failed-AVP AVP.

         PANA_MISSING_AVP                        5005
            Error code from PAA to PaC or from PaC to PAA.  The
            message did not contain an AVP that is required by the
            message type definition.  If this value is sent in the
            Result-Code AVP, a Failed-AVP AVP SHOULD be included in
            the message.  The Failed-AVP AVP MUST contain an example
            of the missing AVP complete with the Vendor-Id if
            applicable.  The value field of the missing AVP should be
            of correct minimum length and contain zeroes.

         PANA_RESOURCES_EXCEEDED                 5006
            Error code from PAA to PaC.  A message was received that
            cannot be authorized because the client has already
            expended allowed resources.  An example of this error
            condition is a client that is restricted to one PANA
            session and attempts to establish a second session.

         PANA_CONTRADICTING_AVPS                 5007
            Error code from PAA to PaC.  The PAA has detected AVPs in
            the message that contradicted each other, and is not
            willing to provide service to the client.  One or more
            Failed-AVP AVPs MUST be present, containing the AVPs that
            contradicted each other.

         PANA_AVP_NOT_ALLOWED                    5008
            Error code from PAA to PaC or from PaC to PAA.  A message
            was received with an AVP that MUST NOT be present.  The
            Failed-AVP AVP MUST be included and contain a copy of the
            offending AVP.

         PANA_AVP_OCCURS_TOO_MANY_TIMES          5009
            Error code from PAA to PaC or from PaC to PAA.  A message
            was received that included an AVP that appeared more often
            than permitted in the message definition.  The Failed-AVP
            AVP MUST be included and contain a copy of the first
            instance of the offending AVP that exceeded the maximum
            number of occurrences.

         PANA_UNSUPPORTED_VERSION                5011
            Error code from PAA to PaC or from PaC to PAA.  This error
            is returned when a message was received, whose version
            number is unsupported.

         PANA_INVALID_AVP_LENGTH                 5014
            Error code from PAA to PaC or from PaC to PAA.  The
            message contained an AVP with an invalid length.  The
            PANA-Error message indicating this error MUST include the
            offending AVPs within a Failed-AVP AVP.

         PANA_INVALID_MESSAGE_LENGTH             5015
            Error code from PAA to PaC or from PaC to PAA.  This error
            is returned when a message is received with an invalid
            message length.

----------
status: Clarifying Text Required -> Text Proposed
________________________________________________
PANA Issues <[email-masked]>
http://danforsberg.info:8080/pana-issues/issue19
________________________________________________

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

---

From: [email-masked]
Date: Mon, 6 Oct 2003 15:24:51 +0300

Ok. So do you want to say that realm based routing is outside 
the scope of PANA and in error case NAS must inform PaC in some 
other means than PANA protocol? I don't mind taking this error 
case away. Anyway, I'm curious of how 802.1X does handle this 
case?

- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 02 October, 2003 20:31
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: [Pana] [issue19] Result-Code AVP values?
> 
> 
> >> We don't have a place where PaC sends the realm information.
> >> So, I can't see
> >> where such an error would be returned to the PaC.
> > 
> > The EAP-Response/Identity contains the realm if it is required. Or
> > should we create a NAI AVP, that contains only the realm? Realm is
> > needed to route the packet to the right AAA backend. If PAA
> > functionality doesn't check the realm, NAS or for example the local
> > AAA proxy will do it. But in the case of unknown realm the client
> > should be notified.
> 
> I should have said "We don't have a place where PaC sends the realm
> information in PANA." You are right that EAP client ID can 
> have this, but
> than it is the responsibility of EAP or EAP method to deal 
> with this. This
> error case should not leak into PANA.
> 
> Alper
> 
>

---

From: [email-masked]
Date: Mon, 6 Oct 2003 16:06:22 +0300

Just one more comment. The usage scenarios document chapter 3 
(problem statement) says that the authentication agent (PAA) 
chooses the backend authentication server based on the identity, 
for example NAI..
- Dan

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 06 October, 2003 15:25
> To: [email-masked]; [email-masked]
> Subject: RE: [Pana] [issue19] Result-Code AVP values?
> 
>

---

From: [email-masked]
Date: Tue, 7 Oct 2003 11:16:30 +0300

> Sent: 06 October, 2003 19:34
> > other means than PANA protocol?
> 
> Yes, I'm thinking that this should be happening transparent to PANA.
> 
> > I don't mind taking this error
> I think this is also an EAP question. What would be the EAP 
> behavior when
> the NAS cannot recognize the EAP client identifier?

You tell me?

- Dan

> From your other message:
> If we were to expand "the authentication agent" from that 
> text, actually it
> should be the "NAS" (draft-ietf-aaa-eap) implementation which 
> needs to deal
> with AAA routing, not "PAA."
> 
> Alper
> 
> 
> 
> 
> > 
> > - Dan
> >

---

From: [email-masked]
Date: Wed, 8 Oct 2003 09:27:58 +0300

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

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

> Sent: 07 October, 2003 20:55
> 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
> 
> 
>

---

From: [email-masked]
Date: Tue, 14 Oct 2003 13:11:24 -0500

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

I agree with Yoshi's comment about not adding a REALM_NOT_SERVED
error code. A simple reject is sufficient.

-Basavaraj

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

---

From: [email-masked]
Date: Tue, 14 Oct 2003 13:11:24 -0500

-Basavaraj

---

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

> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 14 October, 2003 21:03
> To: Alper Yegin
> Cc: Forsberg Dan (NRC/Helsinki); [email-masked]
> On Mon, Oct 13, 2003 at 10:54:03PM -0700, Alper Yegin wrote:
> > 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
> >
> >
> > >

---

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

> Sent: 15 October, 2003 19:24
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> On Wed, Oct 15, 2003 at 11:06:17AM +0300,
> [email-masked] wrote:
> 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.
>
> >
> 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