Subject: RE: [AAA-WG]: Authentication method AVP? (issue 417)

From: <[email-masked]>
Date: Tue, 2 Sep 2003 11:39:43 +0300

David Mitton wrote:
> Okay, can we elaborate more on the intended semantics?
> 
> Is this an informational readout for Accounting as to what auth 
> method was actually used?
> 
> Which end originates it? (if accounting only, then client 
> to Acct server) Which way does it flow? Can we enumerate all the 
> desired values?
>
> How does this relate to the RADIUS attributes and MS VSAs at a 
> protocol gateway?
> 
> We have a day to get this in.

Like I said earlier, not delaying NASREQ is more important than
getting this AVP in (and it could be defined somewhere else,
like Diameter EAP, if necessary).

The AVP would be informational, from the client to the accounting
server. RFC2548 defines the following values for MS-Acct-Auth-Type: 
PAP (1), CHAP (2), MS-CHAP-1 (3), MS-CHAP-2 (4), and EAP (5). 
I guess we need a new IANA-managed namespace for these; 
the initial values could be these for easier translation.

Proposed text:

- New section (possibly after 8.6)

  8.TBD Accounting-Auth-Method AVP

  The Accounting-Auth-Method AVP (AVP Code TBD) is of type 
  Enumerated. A NAS MAY include this AVP in an Accounting-Request 
  message to indicate what authentication method was used to 
  authenticate the user. The following values are defined:

        1  PAP
        2  CHAP
        3  MS-CHAP-1
        4  MS-CHAP-2
        5  EAP

  (BTW, a web page on Microsoft TechNet also shows values NONE (7) and 
  CUSTOM (8), though it's not clear if these are actually ever used.
  Maybe we should include NONE here?)

  <http://tinyurl.com/lxmy> or 
  <http://www.microsoft.com/technet/prodtechnol/windowsserver2003/
  proddocs/datacenter/sag_ias_log2a.asp>

- The IANA considerations also need updates. Proposed text:
  (before 11.1) "This document also creates one new namespace to 
  be managed by IANA, as described in Section 11.5". 

  11.5 Accounting-Auth-Method AVP Values

  As defined in Section 8.TBD, the Accounting-Auth-Method AVP 
  (AVP Code TBD) defines the values 1-5. All remaining values are 
  available for assignment via IETF Consensus [IANA]."

- Section 9: Should we also mention that this AVP could be 
  translated to MS-Acct-Auth-Type VSA? On the other hand, 
  we're not including any translation hints for other VSAs
  (though Diameter EAP will mention the possibility of 
  translating between MS-MPPE-Send/Recv-Key and whatever key AVP 
  it defines).

- Also needs update for this: table in beginning of Section 8, 
  AVP occurrence tables in Sections 10.2.1 and 10.2.2.

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Sep 2003 17:42:27 +0300

>>Which end originates it? (if accounting only, then client 

Client. The auth method avp is simple. Compare this to the
eap auth method avp in diameter eap, which is harder, because
the NAS may not know the authentication method... ;-)

>>We have a day to get this in.

Technically, we could leave the vendor specific translation
to someone else. But that is easy enough as well...
RFC 2548, Section 2.7.4, MS-Acct-Auth-Type <=> our new AVP.

> like Diameter EAP, if necessary).

I think this is simple enough that we should just put in.
I could be wrong, of course...

>   Maybe we should include NONE here?)

We definately need a NONE.

>   available for assignment via IETF Consensus [IANA]."

Ok.

>   translating between MS-MPPE-Send/Recv-Key and whatever key AVP 

Given that the reference is non-standard, if we include translation
then that translation hint has to be non-normative. Perhaps you
could add a paragraph to Section 9 that starts with For example, ...
or add this to an appendix.

>   AVP occurrence tables in Sections 10.2.1 and 10.2.2.

Yes.

--Jari