Subject: [Dime] [ERP] Review and comments, synthesis

From: Sebastien Decugis <[email-masked]>
Date: Thu, 22 Jan 2009 15:04:22 +0900

Here is my review of draft-ietf-dime-erp-00, in [Seb] tags.
I've also copied some pending comments from other people that have not
been addressed yet, AFAIK.

BTW, about the reference to RFC3588 or RFC3588bis, according to the
Milestones of the WG, the rfc3588bis is due in January 2009 and ERP
document is due in May 2009, so I think it makes sense to update the
content to the new revision of base protocol (will affect the reference
to the document and simplify the AVP description). Do you agree?

In short, my main comments are (some are detailed later in the review):
- we should add more details on deployment (ER entities on the route of
EAP exchanges, ...) and detail interoperability issues (if one or more
entity does not support ERP). This document uses the following entities:
Peer, ER authenticator, ER local server, ER home server, EAP local
server (not directly but it may be involved in some cases), EAP home
server. More figures are definitely needed to make the whole thing
understandable...
- I think grouped AVPs could be used to simplify handling on the ER
entities. I also think AVPs should be renamed to ERP-*.
- ER home server and EAP home server are mixed in this document,
clarification is needed.
- In case of implicit ERP bootstrapping, the peer is not notified that
ERP was already bootstrapped. How to prevent ERP bootstraping exchange
to be initiated? (maybe sending a new AVP between ER local server and
authenticator? FFS ;) ). In a general maneer, I think that implicit
bootstrapping of ERP adds more problems than it solves (for example, it
will occur even if the peer does not support ERP). I think we could
simply remove it and mandate explicit bootstrapping for ERP.
- We should also consider the simpler case where the peer is in its home
network. New AVPs are not used, but some description is needed anyway.
- Everytime I write "we should", please read "I can provide a draft for
this, if you agree this is needed"...

Abstract

   EAP Re-authentication Protocol (ERP) defines extensions to the
   Extensible Authentication Protocol (EAP) to support efficient re-
   authentication between the EAP peer and an EAP re-authentication
   server through any EAP/ERP authenticator.

[Julien] I'm wondering if we should note that the authenticator may be
ERP-aware.

[Seb] I agree that only ERP-aware authenticator can be used in Diameter
ERP application. A pure EAP-passthrough NAS would not be able (to be
verified, though) to extract the content of KeyName-NAI to set the
User-Name of the new message, which is mandatory for routing of the ERP
message. This should be written in this document.

   This document specifies
   Diameter support for ERP.  The Diameter EAP application is re-used
   for encapsulating the newly defined EAP codes specified in the ERP
   specification.  Additionally, this document also defines specific
   Diameter processing rules relevant to ERP.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Diameter Support for ERP  . . . . . . . . . . . . . . . . . . . 3
     3.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4
   4.  Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Attribute Value Pair Definitions  . . . . . . . . . . . . . . . 5
     5.1.  EAP-DSRK-Request AVP  . . . . . . . . . . . . . . . . . . . 5
     5.2.  EAP-DSRK AVP  . . . . . . . . . . . . . . . . . . . . . . . 5
     5.3.  EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5
     5.4.  EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5
   6.  AVP Occurrence Table  . . . . . . . . . . . . . . . . . . . . . 5
   7.  AVP Flag Rules  . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     11.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

1.  Introduction

   RFC 4072 [1] specifies a Diameter application that carries EAP
   packets between a Diameter client and the Diameter Server/EAP server.

[Seb] I think some people will not like the "Diameter client" and
"Diameter Server" phrasing... Maybe "EAP authenticator / Diameter EAP
client" and "EAP server / Diameter EAP server" would be more precise?
[Seb] (editorial) In some other RFC, such as 5296, there are links
pointing to the full text of the RFC when a reference appears in the
text (in html version), and sometimes also the title of the RFC is
copied in the title of the link, such as in 5295. I think it is very
convenient, but I don't know if it's a mod in the xml2rfc tool or
changes in the xml file. Is it possible to do the same thing here Julien?

   RFC 5296 [2] defines the EAP Re-authentication Protocol to allow
   faster re-authentication of a previously authenticated peer.

   In ERP, a peer is authenticated by the network thanks to keying

[Seb] I am not sure about this, but I think that ERP provides mutual
authentication of the peer and the network by proof of possession of
material derived from a previous mutual authentication (in full EAP
exchange). Or does this depend on the EAP method that is used? Anyway,
it is probably not important for this document.

   material obtained during a previous EAP exchange.  This keying
   material is derived from the Extended Master Session Key (EMSK) as
   defined in the RFC 5295 [5].  To accomplish the EAP reauthentication
   functionality, ERP defines two new EAP codes - EAP-Initiate and EAP
   Finish.  This document specifies the reuse of Diameter EAP
   Application to carry these new EAP messages.

   ERP is executed between the peer and a server located either in the
   peer's home domain or in the local domain visited by the peer.  In
   the latter case, a Domain Specific Root Key (DSRK) is derived from
   the EMSK, as defined in the RFC 5295 [5], and is provided by the Home
   EAP server to the local domain server. 

[Seb] In my understanding of the ERP mechanism, the home ER server and
home EAP server may be different entities (with some out-of-band
mechanism to transport the usage-specific keys, such as defined in
draft-ietf-hokey-key-mgm-04). I think we should refer to Home ER server
here. This server would anyway have to be on the path of the full EAP
authentication messages, because of Diameter routing mechanism based on
message's application, for ERP to work, since we re-use EAP application
number.

   For that purpose, this
   document specifies the transport of the DSRK using the Diameter EAP
   Application.

[Seb] What happens if there is no local ER server, or the peer is in its
home network and uses ERP? I think the scope of this document is broader
than described here. I believe text should be added in the document to
describe this situation. I can provide a draft text, if you agree that
this is missing.
[Seb] By the way, is there a difference between "realm" and "domain"?
Sorry for the non-native English speaker's question ^^'.

2.  Assumptions

   This document defines only additional optional AVPs for usage with
   the Diameter EAP application.  This document does not define a new
   Diameter application and therefore a new Application ID is not
   required, as described in the Diameter Base protocol [3].

   In this document, when EAP re-authentication is performed in the
   domain visited by the peer, it is assumed that the local ER server is
   co-located with a Diameter agent in the visited domain present in the
   path of the full EAP exchange.  (Editor's Note: it is not clear at
   the time of writing wether this document must require this local AAA
   server to be on the path.)

[Seb] I think every previous review of this document had remarks on this
part. I'll try to clarify according to my understanding.
First of all, this assumption has to be made due to the re-use of
Diameter EAP application. An alternative solution using a different
application ID for ERP would remove this constraint but adds great
complexity and several exchanges to distribute the keys to the ER
entities. I personally believe that using the same application id is
better, since implementing ERP functions on top of EAP (i.e. colocate ER
and EAP servers) is easier than having different boxes for that.
- For ERP implicit or explicit bootstrapping to success, the local ER
server and home ER server *must* be on the path of full EAP
authentication (with home EAP server).
- In addition, once ERP is bootstrapped, the local ER server *must* be
on the path of a (virtual) full EAP authentication with local EAP
server, since the User-Name AVP contains the local domain name
(EMSKname@localdomain).
- What happens if one of these condition is not met is not trivial. I
think in most cases it results in the ERP message not answered, timed
out, and a normal full EAP authentication follow.
I think a new (3.3 ?) section is needed to describe interoperability and
deployment issues such as: what happens if the assumption is not met, or
if one of the entities does not support ERP functions. See my note later
in this review.
Addressing Jouni's comment, we should also consider the current work on
Diameter routing. Especially, with Diameter routing as described in Base
Protocol, the ER local server may be in the path of first EAP exchange
(and add the EAP-DSRK-Request AVP) but not in the next round(s) of a
multi-round EAP exchange, and therefore unable to extract the EAP-DSRK
from the final Success notification, which breaks a strong requirement
of RFC5295. Of course, the ER server could detect that the local ER
server was not in the path (thanks to Route-Record AVPs, and provided
that this ER home server knows which one is the ER local server) of the
last DER and not add this keying material.

3.  Diameter Support for ERP

3.1.  Protocol Overview

   The Diameter EAP Application is used to transport ERP messages
   between the NAS (authenticator) and an authentication server (ER
   server).

   In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER
   server via the authenticator.  Alternatively, the NAS may send an
   EAP-Initiate/Re-auth-Start message to the peer to trigger the start
   of ERP.  In this case, the peer responds with an EAP-Initiate/Re-auth
   message to the NAS.

   The general guidelines for encapsulating EAP messages in Diameter
   from RFC 4072 [1] apply to the new EAP codes defined for ERP as well.
   The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload
   AVP of a Diameter EAP Request (DER) message by the NAS and sent to
   the Diameter server.  The NAS MUST copy the contents of the value
   field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former
   is not present) of the EAP Initiate/Re-auth message into a User-Name
   AVP of the Diameter EAP-Request.

[Seb] I can't find a case where 'KeyName-NAI' TLV would not be in the
ERP message. I think the second part of this sentence should be removed.
If the peer does not have a valid key, it will not initiate ERP at all.

   The ER server processes the EAP-Initiate/Re-auth message in
   accordance with [2] and responds with an EAP-Finish/Re-auth message.
   The Diameter server MUST encapsulate the EAP-Finish/Re-auth message
   within an EAP-Payload AVP of a Diameter EAP Answer message.  In an
   EAP re-authentication successful case, an EAP-Master-Session-Key AVP
   is included in the Diameter EAP Answer (DEA) message that contains
   the Re-authentication Master Session Key (rMSK).  The Diameter
   Result-Code SHOULD be a success Result-Code.  In an EAP re-
   authentication failure case, the Diameter Result-Code AVP of the a
   Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and
   no EAP-Master-Session-Key AVP is present.  (Editor's Note: it is FFS
   if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?)

[Seb] I also agree that MUST conditions for the result-codes seems more
logical here. It should also be noted that if the EAP server does not
support ERP functions it will return a Diameter error, according to
RFC4072: "A Diameter server receiving an EAP-Payload AVP that it does
not understand SHOULD determine whether the error is fatal or non-fatal
based on the EAP Type. A Diameter server determining that a fatal error
has occurred MUST send a Diameter-EAP-Answer with a failure Result-Code
and an EAP-Payload AVP encapsulating an EAP Failure packet. A Diameter
server determining that a non-fatal error has occurred MUST send a
Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no
EAP-Payload AVP."

[Seb] I think a figure is not sufficient here, we need to develop the
different situations (peer in local domain, no local ER server, ...),
each with a figure. This would rather be a separate section, IMHO. I can
provide a draft if you agree.

3.2.  DSRK Request and Delivery

   A local ER server, collocated with a Diameter proxy in the domain
   visited by the peer, may request a DSRK from the home EAP/ERP server,
   either in the initial EAP exchange (implicit bootstrapping) or in an
   ERP bootstrapping exchange (explicit bootstrapping).  This is done by
   including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER)
   message.  The EAP-DSRK-Request AVP contains the domain or server

[Seb] "domain or server" => see my note on this topic later in this
mail. It should not be "or" here anyway.

   identity required to derive the DSRK.

   In successful case, the DSRK is carried by the EAP-DSRK AVP in the
   Diameter EAP Answer (DEA) message.  Along with the EAP-DSRK AVP, an
   EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP-

[Seb] It's not the DSRK's keyname, but the EMSKname. I think the name of
this AVP is error-prone, we should rename it (see a proposal later in
this mail).

   DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.
   (Editor's Note: add a figure ?).

[Seb] I think a new section "Interoperability" is needed to examine
cases where one of the element does not support ERP functions.
[Seb] I think also a new section "Deployment" is needed, to detail the
assumptions: ER servers in the path of EAP exchanges, authenticators
capable of advertizing the domain name that must match the ER local
server's, ... Figures for all the different situations would be very
useful to clarify for everbody. Cases to consider: The peer has a valid
EMSK? The peer knows the local domain name? A local ER server is
present, and bootstrapped for this EAP session? (Actually about this
last point, how does the peer know this information, if implicit
bootstrapping was used???)
I can provide draft text for these sections, if you think they are needed.

4.  Command Codes

   This document re-uses the EAP application commands [1] and does not
   define new command codes.

[LM] this section is not required as there is nothing specific for ERP.
We should skip it.
[Seb] I agree, unless there is a kind of standard template for
Diameter-related RFCs?

5.  Attribute Value Pair Definitions

   This section defines new AVPs for the ERP support within Diameter EAP
   Application.

[Seb] For all the following new AVPs, I think naming convention ERP-*
instead of EAP-* would be better (ERP-DSRK-Request, ...). Any thoughts?

5.1.  EAP-DSRK-Request AVP

[Seb] It has not been discussed (AFAIK) what should happen if several ER
servers are in the path of the full EAP authentication. Can this AVP
appear several times (if we have hierarchy of re-authentication domains,
for example?) I think the answer is no, since the domain name advertized
by the authenticator must match the ER server's domain name. Maybe it
should be written somewhere that the ER server adds this AVP only if no
such AVP is already in the message?

   The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity.
   This AVP fulfills two purposes: first, it indicates that a ERP server
   is located in the local domain that is willing to play the role of an
   ERP server for a particular session.  Second, it conveys information
   about the domain name to the Diameter/EAP/ERP server.  (Editor's
   Note: it is FFS if DiameterIdentity is the correct type).

[Seb] Actually both information may be needed, the local ER server name
(for authorization purpose on the home server for example, and
Autorization Indication TLV in ERP message) and the domain name (can
this domain-name be different from the Origin-Realm?). Therefore I think
a Grouped AVP would be better, containing two sub-AVP for the Domain
name and ER server name.
[Seb] By the way, about discussions if DiameterIdentity type is suitable
for a domain name, I want to highlight that the Origin-Realm AVP (for
example) defined in Diameter Base Protocol is also of DiameterIdentity
type, and does not contain a FQDN, AFAIU.

[JiK] What happens if Diameter server does not understand this AVP but
still returns OK for the full EAP authentication?
[Seb] In that case, the DSRK will not be included in the last message of
the round of exchanges, and the ER local server will know that home
domain does not do ERP, AFAIU. Do you think a note about this is needed?

5.2.  EAP-DSRK AVP

[Seb] Since the following three AVP are always sent together and parsed
together, I believe a Grouped AVP would be nice here. It adds few
overhead and makes parsing of the message on the ER server faster. Any
opinion?

   The EAP-DSRK AVP (AVP Code TBD) is of type OctetString.  This AVP
   contains keying material to be used by the visited domain (i.e. the
   DSRK).  Exactly how this keying material is derived is beyond the
   scope of this document.

[Seb] Maybe reference to the ERP's RFC would be better here, such as
"Exactly how this keying material is derived is described in RFC 5295
and RFC 5296" ?

[Seb] It may also be worth noting that this AVP MUST be removed by the
ER local server that added the EAP-DSRK-Request on the first EAP
exchange (might be several exchanges earlier, leading to routing
constaints...) or ERP bootstrap exchange?

5.3.  EAP-DSRK-Name AVP

   The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString.  This
   AVP contains the EMSKname which identifies the keying material.  How

[Seb] Because the AVP contains the EMSKname, it may be better to rename
it to EAP-EMSK-Name  (or ERP-EMSK-Name)? Because RFC5295 also defines
how to derive DSRKName, so it may be error-prone here.

   this name is derived is beyond the scope of this document and defined
   in [5].

[pending JiK's] if this is a plain text name, use UTF8String. Otherwise
OctetString is OK. AFter reading a bit of the ERP draft it says there
that the 64 bits username part of the NAI is encoded in hexadecimal. In
5.3.2 of ERP draft it is says the username takes up to 128 octets and in
5.3.3 it is though said the username takes up to 16 octets. So I am a
bit confused what the username part actually keeps inside in this AVP
and how it is encoded.

5.4.  EAP-DSRK-Lifetime AVP

   The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and
   contains the DSRK lifetime in seconds.  (Editor's Note: it is FFS if
   Unsigned32 is not sufficient).  (Editor's Note: it is FFS default
   value)

[Seb] There is also a pending comment from Jouni about the "0" value.
Does "default value" refer to this value of 0, or to the case where the
AVP is not included?

6.  AVP Occurrence Table

   The following table lists the AVPs that may optionally be present in
   the DER and DEA commands [1].

                                   +---------------+
                                   |  Command-Code |
                                   +-+-----+-----+-+
      Attribute Name                 | DER | DEA |
      -------------------------------|-----+-----+
      EAP-DSRK-Request               | 0-1 |  0  |
      EAP-DSRK                       |  0  | 0-1 |
      EAP-DSRK-Name                  |  0  | 0-1 |
      EAP-DSRK-Lifetime              |  0  | 0-1 |
                                     +-----+-----+

                 Figure 1: DER and DEA Commands AVP Table

   When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name
   and the EAP-DSRK-Lifetime MUST also be present.

7.  AVP Flag Rules

   The following table describes the Diameter AVPs, their AVP Code
   values, types, possible flag values, and whether the AVP MAY be
   encrypted.  The Diameter base [3] specifies the AVP Flag rules for
   AVPs in Section 4.5.

                                            +---------------------+
                                            |    AVP Flag Rules   |
                                            +----+-----+----+-----+----+
                     AVP  Section           |    |     |SHLD|MUST |    |
  Attribute Name     Code Defined Data Type |MUST| MAY |NOT |NOT  |Encr|
  ------------------------------------------+----+-----+----+-----+----+
  EAP-DSRK-Request   TBD  4.7.1  DiamIdent  |    |  P  |    | V,M | Y  |
  EAP-DSRK           TBD  4.7.2  OctetString|    |  P  |    | V,M | Y  |
  EAP-DSRK-Name      TBD  4.7.3  OctetString|    |  P  |    | V,M | Y  |
  EAP-DSRK-Lifetime  TBD  4.7.4  Unsigned64 |    |  P  |    | V,M | Y  |
  ------------------------------------------+----+-----+----+-----+----+

  Due to space constraints, the short form DiamIdent is used to
  represent DiameterIdentity.

                      Figure 2: AVP Flag Rules Table

8.  Security Considerations

   The security considerations specified in RFC 4072 [1], and RFC 3588
   [3] are applicable to this document.
   EAP channel bindings may be necessary to ensure that the Diameter
   client and the server are in sync regarding the key Requesting
   Entity's Identity.  Specifically, the Requesting Entity advertises
   its identity through the EAP lower layer, and the user or the EAP
   peer communicates that identity to the EAP server (and the EAP server
   communicates that identity to the Diameter server) via the EAP method
   for user/peer to server verification of the Requesting Entity's
   Identity.

[Seb] I can't see what the threat is here, since the key is given to the
authenticator by the AAA proxy (who identifies and authorizes the peer
to act as an authenticator, according to rfc3588) and on the peer's side
it's derived locally from the EMSK. I may be missing the point, sorry
for this...

9.  IANA Considerations

   This document requires IANA registration of the following new AVPs to
   the AVP registry established by RFC 3588 [3]:

   o  EAP-DSRK-Request

   o  EAP-DSRK

   o  EAP-DSRK-Name

   o  EAP-DSRK-Lifetime

10.  Acknowledgments

   Vidya Narayanan reviewed a rough draft version and found some errors.
   Many thanks for her input.

11.  References

11.1.  Normative References

[Seb] I am not sure the difference between "Normative" and "Informative"
but I think that the RFC defining the rules for key derivation in ERP,
5295, should be in Normative section?

   [1]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
        Authentication Protocol (EAP) Application", RFC 4072,
        August 2005.

   [2]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
        authentication Protocol (ERP)", RFC 5296, August 2008.

   [3]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [5]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
        "Specification for the Derivation of Root Keys from an Extended
        Master Session Key (EMSK)", RFC 5295, August 2008.

   [6]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
        Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
        June 2004.

Thank you for reading this veeeeery long mail ^^.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 27 Jan 2009 09:19:26 +0100

Hi sebastien,

 See my comments below and thanks for this careful review.
I think that some of the topics you raised would probably benefit
from separate threads..

On Thu, Jan 22, 2009 at 7:04 AM, Sebastien Decugis <[email-masked]> wrote:
> Hi all,

 it makes sense. Having opinions from others will help to conclude.

> server (not directly but it may be involved in some cases),

 hmm, in which case a local EAP server is involved ? maybe you thought
to a local AAA server ?

> EAP home

 Agree.

> entities.

 You're probably right.

> I also think AVPs should be renamed to ERP-*.

 good idea.

> simply remove it and mandate explicit bootstrapping for ERP.

 If we remove it from AAA support, implicit bootstrapping just won't
work in general. Not sure that we can remove it.

> network. New AVPs are not used, but some description is needed anyway.

 ok

> this, if you agree this is needed"...

 sounds good to me :)

> message. This should be written in this document.

 Yes, normally it will just drop the packets since EAP Code > 4.

> client" and "EAP server / Diameter EAP server" would be more precise?

 Yes

> changes in the xml file. Is it possible to do the same thing here Julien?

 I don't know. I didn't try to generate the html version.

> it is probably not important for this document.

 it does not depend on the EAP method but the key used as an input to
ERP (I think about the EMSK) is first derived from the first EAP
exchange. That was the intention of this sentence.

> message's application, for ERP to work, since we re-use EAP application

 We thought that it would simplify to say that home ER and home EAP
are logically
co-located.

> describe this situation. I can provide a draft text, if you agree that

 Yes, that would be good to document this case.

> Sorry for the non-native English speaker's question ^^'.

 AFAIK, there is no difference.

> Diameter EAP application.

 not really. Diameter EAP application may have the same problem.

> An alternative solution using a different

 not sure to understand. Are you saying that you would prefer "great
complexity" ? :)

 I think we should handle this topic in a specific thread.

> if one of the entities does not support ERP functions. See my note later

 Right.

> If the peer does not have a valid key, it will not initiate ERP at all.

 I guess you're right.

> Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no

 ok. I also think a MUSt makes sense here.

> provide a draft if you agree.

 I agree.

> I can provide draft text for these sections, if you think they are needed.

 It seems to be a good idea .
> [Seb] I agree, unless there is a kind of standard template for

 Lionel's comment was about a old version of this section detailing DER/DEA
message. I would prefer to keep it as it is.

> instead of EAP-* would be better (ERP-DSRK-Request, ...). Any thoughts?

 I'm ok.

> such AVP is already in the message?

 I'm not sure that we can have multiple domains on a AAA path. But this would
probably add security.

> a Grouped AVP would be better, containing two sub-AVP for the Domain

 I think the authorization process will be based on the domain name
and not the local ER
server name.

> type, and does not contain a FQDN, AFAIU.

 Interesting since DiameterIdentity is defined as a FQDN.
> domain does not do ERP, AFAIU. Do you think a note about this is needed?

 A clarification may be useful.
> "Exactly how this keying material is derived is described in RFC 5295

 right.

> how to derive DSRKName, so it may be error-prone here.

 I think you're right.

> Does "default value" refer to this value of 0, or to the case where the

 "0" value could mean infinite I guess.
>   the DER and DEA commands [1].

 This is a "known" issue within EAP Keying Framework concerning Channel Binding.
You can find more info. in RFC 3748 section 7.15:
http://tools.ietf.org/html/rfc3748#page-55

> 5295, should be in Normative section?

 I think so.

> Thank you for reading this veeeeery long mail ^^.

 thanks for this careful review ! I'll send you the xml file to produce
a -01 version based on your comments.

 Regards,

 Julien