Subject: [AAA-WG]: RE: Issue 99: New AVPs to NASREQ for Basic/Digest support

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Wed, 25 Jul 2001 15:24:10 -0500

Pat,

Sounds good. We could modify the individual I-D submission to reflect a
new Diameter application. When do you foresee this as becoming a WG
item?

- Senthil

> -----Original Message-----
> From: ext Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 3:55 PM
> To: Sengodan Senthil (NRC/Boston)
> Cc: [email-masked]; [email-masked]; ext Bernard Aboba;
> [email-masked]; Chan Tat (NRC/Boston); Srinivas Bindignavile
> (NRC/Boston); Costa-Requena Jose (NMP/Helsinki)
> Subject: Re: Issue 99: New AVPs to NASREQ for Basic/Digest support
> 
> 
> Given where we are in the standardization process, I would prefer that
> we not add new features to the specifications. I believe that fixes
> to bugs in the current specs is acceptable, though.
> 
> Having said that, I believe that the proposal to support Basic/Digest
> support is very important. However, I believe that it would 
> be preferable
> to create a new Diameter application, and not require any 
> changes to the
> NASREQ extension.
> 
> So, personally, I'd prefer to reject this issue, and require a new
> I-D (which I believe already exists).
> 
> Thanks,
> 
> PatC
> On Wed, Jul 25, 2001 at 02:51:52PM -0500, Sengodan Senthil 
> (NRC/Boston) wrote:
> > Submitter name: Srinivas, Chan, Sengodan, Costa-Requena
> > Submitter email address: [email-masked],
> > [email-masked], [email-masked],
> > [email-masked]
> > Date first submitted: July 25, 2001
> > Reference:
> > 
http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t
> xt
> Document: Document Requiring change:  nasreq
> Comment type: 'T'echnical
> Priority: '1'  
> Section: 3.1 and Introducing New Section 4.0
> Rationale/Explanation of issue: Three new AVPs are introduced in
NASREQ
> in order to support Basic/Digest authentication. Detailed description
is
> found in the individual draft submission
>
http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t
> xt.
>  
> Proposal:
> Section 3.1.1:  Paragraph added before Message Format to read: "The
> Resource and Response AVPs (defined in Section 4.0) MAY be present in
> the AA-Request message when Basic or Digest authentication is to be
> used." 
> Section 3.1.1: AAR Command modified to include [ Resource ] and [
> Response ] AVPs.
> Section 3.1.2: Paragraph added before Message Format to read: "The
> Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer
> message when Basic or Digest authentication is to be used."
> Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs.
> Section 4.0 is introduced and includes the following text (while
> original Section 4.0 changes to 5.0 and so on):
> 4.0  Basic/Digest Authentication Support
> The Basic and Digest authentication schemes, described in [X], are two
> well-known authentication methods. This section describes the AVPs
that
> are required for Basic/Digest authentication support within the
Diameter
> protocol. As seen in Section 3.0, the Resource AVP and Response AVP
MAY
> be used within the AA-Request Command, while the Challenge AVP MAY be
> uesd within the AA-Answer Command.
> 4.1  Resource AVP
> The Resource AVP (AVP Code xxx) is of type OctetString and is used to
> convey a resource. It MAY be used by a DIAMETER client to convey to
the
> DIAMETER server the resource whose access needs authorization.
> 4.2  Challenge AVP
> The Challenge AVP (AVP Code xxx) is of type OctetString and is used to
> convey a challenge. It MAY be used by a DIAMETER server to convey a
> challenge to the DIAMETER client.
> 4.3  Response AVP
> The Response AVP (AVP Code xxx) is of type OctetString and is used to
> convey a response. It MAY be used by a DIAMETER client to convey a
> response to the DIAMETER server.
> 
> Comments/Discussion (not part of proposed text):
> No separate command code has been proposed for Basic/Digest
> authentication, and the AAR and AAA commands have been modified to
> support the proposed AVPs. This implies that when a DIAMETER server
> receives an AAR command from a DIAMETER client, it cannot determine
> whether the authentication/authorization schemes are RADIUS based or
> Basic/Digest based just by looking at the command code. Instead, the
> AVPs have to be parsed to determine this. If this is seen as an issue,
> then a new command code may have to be introduced for the purpose of
> Basic/Digest authentication support. This would then be along the
lines
> of a new command code being introduced for the purpose of EAP
> authentication support. 
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 25 Jul 2001 13:20:46 -0700

On Wed, Jul 25, 2001 at 03:24:10PM -0500, Sengodan Senthil (NRC/Boston) wrote:
> new Diameter application.

That would be the best approach.

> When do you foresee this as becoming a WG
> item?

That is a question for the chairs to answer.

PatC