Subject: RE: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method?

From: <[email-masked]>
Date: Wed, 18 Jun 2003 21:50:50 +0300

Bernard Aboba wrote:

> > (or Expanded Type) field in the last Diameter-EAP-Request's
> > EAP-Payload AVP.
> 
> Unfortunately, that would be likely to be EAP Success (no Type).

The last Diameter-EAP-Answer of course contains an EAP Success,
but the last Diameter-EAP-Request probably contains an EAP Response
of the correct type, right?

> > Or the Diameter server could give the value
> > to use in the last (success) Diameter-EAP-Answer. Any other ideas?
> 
> I'd suggest that perhaps the Type is determined from the method in
> progress at the time the EAP Success was determined.  The equivalent
> functionality is in RADIUS (See RFC 2548) so there must be a 
> reliable way to do it somehow...

Thanks for the pointer, I hadn't noticed that RFC 2548 includes
a similar attribute (MS-Acct-EAP-Type).

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2003 13:04:33 +0300

Pasi wrote:
> One possible solution would be that the
> Accounting-EAP-Auth-Method AVP will be equal to the Type 
> EAP-Payload AVP.  Or the Diameter server could give the value
> to use in the last (success) Diameter-EAP-Answer. 

Bernard wrote:
> progress at the time the EAP Success was determined.

> of the correct type, right?

I would actually like to use the Diameter server approach that
Pasi outlined above. The main reason for this is that it is
the only entity in the AAA chain that actually knows all the
details associated with the authentication. For instance, if
and when we will have tunneled authentication, the NAS will not
be able to see inside the tunnel for what's happening there.
So I'd like the server to return an AVP to the NAS, which can then
use it on an accounting message. In addition, I'd like to allow
more than one instance of this AVP, to cater for the case where
there indeed has been multiple authentication methods.

Finally, backwards compatibility with RADIUS needs to be dealt
with. I don't think RFC 2869bis had this attribute so we only
need to deal with vendor specific attribute in RFC 2548.

Here's suggested text:

(1) Change Diameter-EAP-Answer BNF to have zero or more
     EAP-Auth-Method AVPs.

(2) Section 4.1.2 (EAP-Auth-Method AVP)

    The EAP-Auth-Method AVP (AVP Code 401) is of type Enumerated
    and uses the EAP Type name space defined in [EAPTYP]. The
    Diameter server MAY return zero or more instances of this attribute
    in the last Diameter-EAP-Answer message it sends for a given
    session. The value given for the AVP is the EAP method
    used in the authentication of the session. In case tunneled
    authentication is used, there may more than one such method,
    and all of them MAY be included.

    The Diameter client SHOULD copy the received EAP-Auth-Method
    AVPs to the Diameter-Accounting-Request messages it sends.
    The order of the AVPs MUST be retained.

(3) Change 5.1 by adding this:

       EAP-Auth-Method                        |  0  |  0+ |

(4) Change 5.2 by replacing this

       Accounting-EAP-Auth-Method             |  1  | 0-1 |

     with

       EAP-Auth-Method                        |  0+ |  0  |

(5) We have earlier talked about the need for text that
     describes RADIUS interoperability. You could add this
     there:

   There is no standard attribute corresponding to EAP-Auth-Method AVP
   in RADIUS. When translating a Diameter message to a RADIUS
   message, all EAP-Auth-Method AVPs are in general discarded.
   When translating a RADIUS message to a DIAMETER message, the
   translation agent is also unable to add any EAP-Auth-Method AVPs
   to the Diameter message.

   Note that vendor-specific RADIUS attributes related to the
   EAP-Auth-Method AVP exist, for instance in [RFC 2548]. Typically,
   these attributes can be translated to the EAP-Auth-Method AVP
   no accounting messages, but since they are not used in the
   authentication and authorization messages, such translations
   require support in the RADIUS-based NAS for determining the
   used authentication methods.

> The equivalent functionality is in RADIUS so there must be a

Since when has that been a proof of the existence of a reliable
way? ;-)

--Jari