Subject: [AAA-WG]: Diameter EAP -05

From: <[email-masked]>
Date: Mon, 5 Apr 2004 14:39:35 +0300

Hi,

I have submitted an updated version of the Diameter EAP
application draft. I believe this version resolves
the following issues from WGLC:

-  450: Comments on EAP-04 (from Jari Arkko), except one item below
-  455: User-name handling (from Joe Salowey)
-  458: Editorial Comment on EAP-04 (from Yoshihiro Ohba)
-  461: Alternate uses and conflicting AVPs (from Joe Salowey)

Temporary copy of -05 and HTML diff from -04 is available from 
http://www.cs.hut.fi/~peronen/eap/diameter_eap.html

This leaves us with the following open issues:

-  446: Diameter EAP comments (from Julien Bournelle). 
   It seems that this issue does not currently propose any 
   changes to the specification. Any objections to closing it?

-  One item from 450: "Section 2.8.5 may be in conflict with 
   EAP channel bindings. Perhaps you should recommend that the 
   diameter server at least sends all AVPs to the backend auth 
   server." Any suggestions for text?

-  460: Key Name AVP (from Joe Salowey). Some discussion about
   how to handle this would be welcome. E.g. pros and cons
   of adding an AVP that we don't have any use for yet (and may 
   not have for some time)? And what exactly is named, MSK or 
   EAP-Key SA or something else?

Best regards
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Apr 2004 17:02:40 +0300

> -  450: Comments on EAP-04 (from Jari Arkko), except one item below
(snip)
>    server." Any suggestions for text?

How about this to the end of 2.8.5:

"A disadvantage of this approach is that it becomes harder
to support so called EAP channel bindings described in
Section 7.15 of [RFC2284bis]. The reason for this is that
entity performing the EAP authentication needs to be aware
of all authorization data related to the session. It is
therefore RECOMMENDED that the backend authentication
server both accepts incoming authorization AVPs as well as
returns authorization AVPs. (How the backend server finds
out which authorization AVPs to return is outside the
scope of this specification.)"

Another approach would be to delete the whole section.

--Jari