Subject: RE: [AAA-WG]: [New Issue] Can Answer be rejected?

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 24 Aug 2001 09:33:38 +0200

Hej Tony,

I was aware of that issue, but it remains unclear in the 
draft whether or not an answer could be rejected (E) back
towards the originator of the answer?

In other words, when a client sends a request, it can be
rejected by any of the agents towards the Home, or even
the home itself, of course. In such a case, the message will
have the R bit cleared, and the E bit set, and will be
sent to the client.

However, when the Home answers the request without 
indicating an error (in the Answer message), is there 
any possibilities that the client or any agents decide to 
reject the Answer, by returning it with the E bit set
towards the Home, instead of the client?

From what I understand now, that should not be possible,
meaning that a message with the E bit set should ONLY be
directed towards clients, in response to a request.
Do I understand it correctly?

My confusion is that, as far as I remember, it used to be
possible a few months back. However, I much prefer the 
Home to receive an STR in that case, like it seems to be 
suggested now.

If some clear statements on that could be added to the 
draft, it would be perfect.

Cheers,
Martin

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 7:09 PM
> To: Martin Julien (ECE)
> Cc: [email-masked]'
> Subject: Re: [AAA-WG]: [New Issue] Can Answer be rejected?
> 
> 
> Martin,
> 
> I believe that we already have an issue on this, which will go in to
> base -08. It's part of issue 107 in the issue list..
> 
> /Tony
> 
> Issue 107: More editorial comments
> Submitter name: Tony Johansson
> Submitter email address: [email-masked]
> Date first submitted: July 31th, 2001
> Reference: N/A
> Document: base
> Comment type: E
> Priority: 2
> Section:
> Rationale/Explanation of issue:
> 
> ....
> 
> Page 68, section 6.2.2, 3rd and 4th paragraph:
> "If the agent receives an answer message with a Result-Code AVP
> indicating success, and it wishes to modify the AVP to indicate an
> error, it MUST issue an STR on behalf of the access device. The agent
> MUST then send the answer to the host which it received the original
> request from."
> 
> The above paragraph needs to better clarify what the relay/proxy agent
> sends back to the access device.
> 
> Suggested change:
> "If the agent receives an answer message with a Result-Code AVP
> indicating success, and it wishes to modify the AVP to indicate an
> error, it MUST issue an STR on behalf of the access device. The agent
> MUST then send the answer to the access device with the modified
> Result-Code AVP indicating the error and MUST also add the
> Error-Reporting-Host AVP, which will contain the identity of this
> agent."
> 
> .....
> 
> 
> 
> "Martin Julien (ECE)" wrote:
> 
> > Issue: Can Answer be rejected?
> > Submitter name: Martin Julien
> > Submitter email address: [email-masked]
> > Date first submitted: 23/08/01
> > Reference:
> > Document: Base
> > Comment type: T
> > Priority: 1
> > Section:
> > Rationale/Explanation of issue:
> >
> > It is not really clear in the draft whether or not answer
> > messages can be rejected. Should it be allowed or not?
> >
> > That needs to be clarified in the draft.
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 24 Aug 2001 07:41:22 -0700

> towards the originator of the answer?

so perhaps a simple sentence is needed here.

> towards the Home, instead of the client?

the state machine makes this quite clear in the following:

   Pending   Error processing successful    Sent STR   Discon
             Service-Specific authorization
             answer

> Do I understand it correctly?

a request can be initiated by a server, so your statement is
incorrect. However, you are correct that the 'E' bit is only
sent in response to a request.

> possible a few months back.

Not to my knowledge. There were some discussions on the list,
but we never introduced a three way handshake.

> However, I much prefer the 

correct. That's what the state machine says.

> draft, it would be perfect.

ok

PatC

---

From: "Kevin Purser" <[email-masked]>
Date: Fri, 24 Aug 2001 09:57:27 -0700

All,

Regarding NASREQ-07, I am aware that the Chap-Password AVP will be
re-written as a grouped AVP (as per issue #115) in the next version of the
spec, which will most likely include an AVP to indicate the CHAP identifier.

I wanted to ask if this new grouped AVP would also include an additional AVP
to indicate the algorithm used in calculation of the password.  This
additional AVP would correspond to the Algorithm field of the
authentication-protocol configuration option packet as specified in section
3 of RFC 1994-PPP Challenge Handshake Authentication Protocol.

Kev

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 24 Aug 2001 10:29:03 -0700

> spec, which will most likely include an AVP to indicate the CHAP identifier.

Correct. The text is as follows:

3.1.1.2  CHAP-Auth AVP

   The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains
   the information necessary to authenticate a user using the
   PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the
   CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see
   section 3.1.1.5) MUST be present as well. Its Data field has the
   following ABNF grammar:

      CHAP-Auth  ::= < AVP Header: TBD >
                     { CHAP-Ident }
                     { CHAP-Response }

3.1.1.3  CHAP-Ident AVP

   The CHAP-Ident AVP (AVP Code 410) is of type OctetString and 
   contains the one octet CHAP Identifier used in the computation
   of the CHAP response [6].

3.1.1.4  CHAP-Response AVP

   The CHAP-Response AVP (AVP Code 411) is of type OctetString and 
   contains the 16 octet authentication data provided by the user
   in response to the CHAP challenge [16]. The actual computation of
   the CHAP response can be found in [6].

> 3 of RFC 1994-PPP Challenge Handshake Authentication Protocol.

CHAP has been in use for many years (well, at least since 96), and to date
there has yet been any new algorithms defined for CHAP. I would argue that
any new auth schemes are being defined for EAP, and not CHAP. Therefore, I
don't see a need to support this AVP at this time.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Fri, 24 Aug 2001 14:03:10 -0400

Pat, if CHAP-Auth is now grouped, why not move the challenge into it?
When would a challenge ever be present without the response?

MS-CHAP does exist and (unless I'm misremembering) does use a different
algorithm id.  Sure it's not standard, but it is at least documented.

Regards,
Barney

---

From: James Carlson <[email-masked]>
Date: Fri, 24 Aug 2001 14:33:34 -0400 (EDT)

Barney Wolff writes:
> algorithm id.

It does.  In fact, it uses two -- 0x80 for MS-CHAPv1 and 0x81 for
MS-CHAPv2.

>  Sure it's not standard, but it is at least documented.

Yep: Informational RFC 2433 for MS-CHAPv1 and 2759 for MS-CHAPv2.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 24 Aug 2001 14:14:09 -0700

Right, but there are separate RADIUS attributes for use with MS-CHAPn. These
same attributes could be used in Diameter as well, right? Is there any
additional work really required?

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 26 Aug 2001 17:29:35 -0700

Pat Calhoun [mailto:[email-masked]] writes:

> there has yet been any new algorithms defined for CHAP.

True, but why not future-proof Diameter?  After all, RC4 was beleived to be
fairly secure until recently; what if something similar happens WRT MD5?  I
would also include the Chap-Challenge in this group, for that matter...

> I would argue that

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 26 Aug 2001 17:35:04 -0700

ok, I will work out the details of adding an algorithm ID, and will
post the result early this week.

PatC