Subject: [Dime] Review of the Diameter ERP draft

From: <[email-masked]>
Date: Wed, 7 Jan 2009 12:03:25 +0100

Hi,

Here is my review for the Diameter ERP draft.

General comments:

- About alignment with RFC 5296:
the draft needs to be updated according to the publication of the RFC 5296. Some proposals are provided below.

- About ER server/AAA agent co-location:
In my understanding, it is assumed in this document ER server and AAA proxy have to be co-located to be able to rely on Diameter to transport ERP specific AVPs. This doesn't maybe preclude other architectural choices but there are outside the scope of this document. It is necessary to clarify this point in this document.

- ERP support discovery:
As the ERP specific AVPs are introduced with the M-bit cleared,  these AVPs are purely optional for the Diameter EAP application i.e. they can be silently ignored by Diameter servers that do not understand this new AVPs. Some text should be provided to describe how the local ER server discovers that the Home EAP server doesn't support ERP and the behaviour of the local ER server in that case.

Hereafter is the rest of my review with comments and proposals.

Best Regards,

Lionel

***************************************

Abstract

   An EAP extension, called "EAP Re-authentication Protocol (ERP)", has
   been specified that supports an EAP method-independent protocol for
   efficient re-authentication between the peer and the server through
   an authenticator.  This document specifies Diameter support for ERP.
   The Diameter EAP application is re-used for encapsulating the newly
   defined EAP Initiate and EAP Finish messages specified in the ERP
   specification.  AVPs for request and delivery of Domain Specific Root
   Keys from the AAA/EAP server to the ER server are also specified.
   Additionally, this document also specifies Diameter processing rules
   relevant to ERP.

[LM] some abusive verbiage in the abstract:

Proposal for new abstract:

   "EAP Re-authentication Protocol defines extensions of EAP to support 
   efficient re-authentication between the peer and an EAP
   re-authentication server through any authenticator. This document 
   specifies Diameter support for ERP. The Diameter EAP application is
   re-used for encapsulating the newly defined EAP messages specified 
   in the ERP specification. Additionally, this document also defines
   specific Diameter processing rules relevant to ERP."

1.  Introduction

   RFC 4072 [1] specifies a Diameter application that carries EAP
   packets between a Diameter client and the Diameter Server/EAP server.
   [2] defines the EAP Re-authentication Protocol to allow faster re-
   authentication of a previously authenticated peer.

[LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] defines the EAP Re-authentication Protocol (ERP)

   In ERP, a peer
   authenticates to the network by proving possession of key material
   derived during a previous EAP exchange.  

[LM] s/a peer authenticate to/a peer is authenticated by

   For this purpose, an
   Extended Master Session Key (EMSK) based re-authentication key
   hierarchy has been defined [5].  ERP may be executed between the ER
   peer and an ER server in the peer's home domain or the local domain 
   visited by the peer. In the latter case, a Domain Specific Root Key
   (DSRK), derived from the EMSK, is provided to the local domain ER
   server.  

[LM] s/is provided to/is provided by the Home ER server to

   The peer and the local server subsequently use the re-
   authentication key hierarchy from the DSRK to authenticate and derive
   authenticator specific keys within that domain.

[LM] this information can be found in the RFC 5296. Remove the sentence above.
   
   To accomplish the
   reauthentication functionality, ERP defines two new EAP codes - EAP
   Initiate and EAP Finish.

[LM] s/ERP defines two new EAP codes/ERP defines two new EAP messages

   This document specifies the reuse of
   Diameter EAP application to carry these new EAP messages.
   The DSRK can be obtained as part of the regular EAP exchange or as
   part of an ERP bootstrapping exchange.  The local ER server
   requesting the DSRK needs to be in the path of the EAP or ERP
   bootstrapping exchange in order to request and obtain the DSRK.  This
   document also specifies how the DSRK is transported to the local ER
   server using Diameter.

[LM] Finally, i would reorganize the last part as follow:

:::::::::::

   "In ERP, a peer is authenticated by the network thanks to keying material
   obtained during a previous EAP exchange.  This keying material is derived
   from the Extended Master Session Key (EMSK) defined in the RFC 5295 [5]. 
   To accomplish the EAP reauthentication functionality, ERP defines two new
   EAP messages - 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. For that purpose, this document specifies the transport of the DSRK
   using the Diameter EAP Application."

::::::::::::::

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

   This document uses terminology defined in [6], [5], [2], and [1].

3.  Assumptions

   This document defines additional optional AVPs for usage with the
   Diameter EAP application.  Routing of these messages is therefore
   provided via the Diameter Application Identifier (among other
   elements), as specified by the Diameter Base protocol [4].

[LM] To avoid any ambiguity I would say:

   "This document defines only additional optional AVPs for usage with
    the Diameter EAP application. This document does not defined
    a new Diameter application and a new Application ID is therefore not
    required, as described in the Diameter Base protocol [4]."
 
   Based on
   the deployment of ERP, a local Diameter server (the same entity
   serves as a Diameter proxy during the full EAP authentication) may
   play the role of the ER server for future re-authentication attempts.
   As such, the local Diameter server requesting the DSRK needs to be in
   the path of the current EAP exchange between the peer and the EAP
   server and also along in the future.  The Diameter client is
   furthermore assumed to be able to route the re-authentication
   messages to the ER server.

[LM] I think that the assumption all along this document is that the local ER server  and the AAA agent are co-located, to be able to rely on DEA for the transport of DSRK.  In that case, I would say something like:

   "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."

4.  Diameter Support for ERP

4.1.  Protocol Overview

   Diameter may be used to transport ERP messages between the NAS
   (authenticator) and an authentication server (ER server).

[LM] s/may/is (the use of Diameter is a pre-requisite in this draft)

   In ERP, the peer sends an EAP Initiate Reauth message to the ER
   server via the authenticator.

[LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth message" (same all along  the document)

   Alternatively, the NAS may send an EAP
   Initiate Reauth-Start message to the peer to trigger the start of
   ERP; the peer then responds with an EAP Initiate Reauth message to
   the NAS.

[LM] s/"EAP Initiate Reauth-Start message"/"EAP-Initiate/Re-auth-Start message" (same  all along the document)

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

[LM] I think that we are talking about the 'keyName-NAI' TLV and not anymore the  'rIKName as NAI' TLV. Moreover, in which case the peer-id TLV would not be present for  ERP?

   The ER server processes the EAP Initiate Reauth message in accordance
   with [2], and if that is successful, it responds with an EAP Finish
   Reauth message indicating a success ('R' flag set to 0).  The
   Diameter server MUST encapsulate the EAP Finish Reauth message with
   the R flag set to zero in an EAP-Payload AVP attribute of a Diameter
   EAP-Answer message.  An EAP-Master-Session-Key AVP included in the
   Diameter EAP-Answer contains the Re-authentication Master Session Key
   (rMSK).  The Diameter Result Code, if any, SHOULD be a success Result
   Code.

   If the processing of the EAP Initiate Reauth message resulted in a
   failure, the Diameter server MUST encapsulate an EAP Finish Reauth
   message indicating failure ('R' flag set to 1) in an EAP-Payload AVP
   of a Diameter EAP-Answer message.  The Diameter Result Code, if any,
   SHOULD be a failure Result Code.  Whether an EAP Finish Reauth
   message is sent at all is specified in [2].

[LM] the use of the 'R' flag is not relevant for Diameter EAP.
[LM] according to the RFC, the EAP-Finish/Re-auth is sent back in any case, success or  failure.
[LM] according to the above comments, I would rephrase the text as follow:

   "The ER server processes the EAP Initiate Reauth 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 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 of
   the a Diameter EAP-Answer message SHOULD be a failure Result-Code and
   no EAP-Master-Session-Key AVP is present."

[LM] By the way, I don't understand the "SHOULD" for the result-code. Any reason not to use "MUST" here?
[LM] a figure could be added for illustration here.

4.2.  DSRK Request and Delivery

   A local ER server, collocated with a Diameter proxy in the peer's
   visited domain,

[LM] s/in the peer's visited domain/in the domain visited by the peer

   may request a DSRK from the EAP server, either in the
   initial EAP exchange (implicit bootstrapping) or in an ERP
   bootstrapping exchange (explicit bootstrapping).  It does this by
   including the EAP-DSRK-Request AVP in the Diameter EAP-Response
   message.  The EAP-DSRK-Request AVP contains the domain or server
   identity required to derive the DSRK.

[LM] the EAP-DSRK-Request AVP is included in the Diameter EAP-Request (and not in the  response)

   An EAP server MAY send the DSRK when it receives a valid Diameter
   EAP-Request message containing an EAP-DSRK-Request AVP.  An ER server
   MUST send the DSRK (or send a failure result) when it receives a
   valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP
   along with a valid EAP Initiate Re-auth packet with the bootstrapping
   flag turned on.  If an EAP-DSRK-Request AVP is included in any other
   Diameter EAP-Request message, the Diameter server MUST reply with a
   failure result.  An EAP-DSRK AVP MUST be used to send a DSRK; an EAP-
   DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP-
   DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.

[LM] I don't understand the intention of the above text. Could it be enough to say:

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

[LM] a figure could be added for illustration here.

5.  Command Codes

[LM] this section is not required as there is nothing specific for ERP. We should skip  it.

[SKIP]

6.  Attribute Value Pair Definitions

6.1.  EAP-DSRK-Request AVP

   The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity.

[LM] s/EAP-DSRK AVP/EAP-DSRK-Request AVP

   This
   AVP fulfills two purposes: First, it indicates that a ER server is
   located in the local domain that is willing to play the role of an ER
   server for a particular session.  Second, it conveys information
   about the domain and ER server identity to the Diameter/EAP server.

[LM] the use of this AVP is explained above. There is no need to explain again. Moreover, if a DiameterIdentity is used, it is to indicate a server and not a domain.  Right? 

6.2.  EAP-DSRK AVP

   The EAP-DSRK AVP (AVP Code TBD) is of type OctetString.  The Domain
   Specific Root Key (DSRK) is carried in this payload.

6.3.  EAP-DSRK-Name AVP

   The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString.  This
   AVP contains the name of the DSRK key that is later used during the
   re-authentication exchange to select the correct DSRK.

[LM] skip the part starting by "that is..."

6.4.  EAP-DSRK-Lifetime AVP

   The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and
   contains the DSRK lifetime in seconds.

7.  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 4: 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.

8.  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 [4] 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 5: AVP Flag Rules Table

[LM] this table is ok according to the current RFC 3588. I don't know how to deal with it regarding the RFC3588bis...

9.  Security Considerations

   The security considerations specified in RFC 4072 [1], and RFC 3588
   [4] 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.

10.  IANA Considerations

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

   o  EAP-DSRK-Request

   o  EAP-DSRK

   o  EAP-DSRK-Name

   o  EAP-DSRK-Lifetime

> -----Message d'origine-----
> De : Hannes Tschofenig [mailto:[email-masked]]
> Envoyé : mardi 6 janvier 2009 14:58
> À : BOURNELLE Julien RD-CORE-ISS; [email-masked]; 
> [email-masked] Cc : MORAND Lionel RD-CORE-ISS Objet : RE: 
> Diameter ERP
> 
> Hi Lionel,
> 
> No objections. 
> 
> Please also keep in mind that you have to complete the work on 
> http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-02.txt
>  
> Ciao
> Hannes
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]
> >Sent: 06 January, 2009 13:33
> >To: [email-masked]; [email-masked]; 
> >[email-masked]
> >Cc: [email-masked]
> >Subject: RE: Diameter ERP
> >
> >Hi all,
> >
> > Lionel also whishes to work with us on this document.
> >
> > First task is to reply to jouni's comment. I'll send you a
> draft reply
> >in the week.
> >
> > happy new year !
> >
> > Julien
> >
> >> -----Message d'origine-----
> >> De : Hannes Tschofenig [mailto:[email-masked]]
> >> Envoyé : mardi 6 janvier 2009 11:16 À : [email-masked]; 
> >> BOURNELLE Julien RD-CORE-ISS; [email-masked] Objet : 
> >> Diameter ERP
> >> 
> >> Hi Julien, Hi Sebastien, Hi Lakshminath,
> >> 
> >> I would like you three to work together on the document. 
> >> Please make some progress. 
> >> 
> >> The XML version of the draft (-00 and -01) can be found here: 
> >> http://www.tschofenig.priv.at/svn/draft-dondeti-dime-erp-diameter/
> >> 
> >> Ciao
> >> Hannes
> >> 
> >> 
> >
> 
> 
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 8 Jan 2009 11:18:13 +0100

Hi lionel,

 some comments inline.

> As the ERP specific AVPs are introduced with the M-bit cleared,  these AVPs are purely optional for the Diameter EAP application i.e. they can be silently ignored by Diameter servers that do not un…

 I agree with these general comments.

>   re-authentication server through any authenticator.

 I'm wondering if we should note that the authenticator may be ERP-aware.
I'm thinking about the case where the authenticator sends the
EAP-Initiate/Re-auth-Start
(Figure 4 in RFC 5296)

> This document

 ok

> [LM] this information can be found in the RFC 5296. Remove the sentence above.

 It may help the reader to understand the purpose of this DRSK.

> [LM] s/ERP defines two new EAP codes/ERP defines two new EAP messages

 I would prefer to say that ERP defines two new EAP Codes here. These newly
EAP packets are then carried in messages (dependent of the protocol used).

> [LM] Finally, i would reorganize the last part as follow:

 First paragraph is the old and second the new ?

 ok

>    with a Diameter agent in the visited domain present in the path of the full

 ok

> [LM] I think that we are talking about the 'keyName-NAI' TLV and not anymore the  'rIKName as NAI' TLV.

 Considering section 5.3.2 of RFC 5296. I agree.

>Moreover, in which case the peer-id TLV would not be present for  ERP?

 Privacy ?

> [LM] By the way, I don't understand the "SHOULD" for the result-code. Any reason not to use "MUST" here?

 I think a MUST would be better. Different views ?

> [LM] the EAP-DSRK-Request AVP is included in the Diameter EAP-Request (and not in the  response)

 yes.

>   EAP-DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.

 Agree.

> [LM] the use of this AVP is explained above. There is no need to explain again.

 As we are in the AVP Definitions, I think it is better to keep some
text explaining it. No ?

> Moreover, if a DiameterIdentity is used, it is to indicate a server and not a domain.  Right?

 In my understanding the local ER server only sends the Domain Name
which will then be
used to compute keys. Maybe the type DiameterIdentity is not
appropriated and we should
use UTF8String instead. What do you think ?

> [LM] skip the part starting by "that is..."

 ok

>   the DER and DEA commands [1].

 That's indeed a good question :).

 And that's all for my comments of your comments.

 Regards,

 --Julien--

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 8 Jan 2009 14:55:22 +0200

One of the things I was not quite sure with the current protocol design
is whether a Diameter application or just a bunch of AVPs are required.
Based on the discussions a few of us when some of the HOKEY specs went
to the IESG / IETF Last Call I got the impression that one has to define
a new Diameter application (which would be based on Diameter EAP) since
you assume that the messages are routed via a node in the local network
and the support for ERP has to be ensured. 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Julien Bournelle
>Sent: 08 January, 2009 12:18
>To: [email-masked]; Sebastien Decugis; [email-masked]
>Subject: Re: [Dime] Review of the Diameter ERP draft
>
>Hi lionel,
>
> some comments inline.
>
>On Wed, Jan 7, 2009 at 12:03 PM, 
><[email-masked]> wrote:
>>
>> Hi,
>>
>> the draft needs to be updated according to the publication 
>of the RFC 5296. Some proposals are provided below.
>>
>> In my understanding, it is assumed in this document ER 
>server and AAA proxy have to be co-located to be able to rely 
>on Diameter to transport ERP specific AVPs. This doesn't maybe 
>preclude other architectural choices but there are outside the 
>scope of this document. It is necessary to clarify this point 
>in this document.
>>
>> - ERP support discovery:
>> As the ERP specific AVPs are introduced with the M-bit 
>cleared,  these AVPs are purely optional for the Diameter EAP 
>application i.e. they can be silently ignored by Diameter 
>servers that do not understand this new AVPs. Some text should 
>be provided to describe how the local ER server discovers that 
>the Home EAP server doesn't support ERP and the behaviour of 
>the local ER server in that case.
>
>
>EAP-Initiate/Re-auth-Start (Figure 4 in RFC 5296)
>
>
>> This document
>> [LM] s/[2] defines the EAP Re-authentication Protocol/RFC 5296 [2] 
>> defines the EAP Re-authentication Protocol (ERP)
>>
>>   In ERP, a peer
> I would prefer to say that ERP defines two new EAP Codes 
>here. These newly EAP packets are then carried in messages 
>(dependent of the protocol used).
>
>>
>> [LM] I think that the assumption all along this document is 
>that the local ER server  and the AAA agent are co-located, to 
>be able to rely on DEA for the transport of DSRK.  In that 
>case, I would say something like:
>>
>> [LM] s/"EAP Initiate Reauth-Start 
>message"/"EAP-Initiate/Re-auth-Start 
>> message" (same  all along the document)
>>
>> [LM] I think that we are talking about the 'keyName-NAI' TLV 
>and not anymore the  'rIKName as NAI' TLV.
>
>> [LM] By the way, I don't understand the "SHOULD" for the 
>result-code. Any reason not to use "MUST" here?
>
>> [LM] the EAP-DSRK-Request AVP is included in the Diameter 
>EAP-Request 
>> (and not in the  response)
>
> yes.
>
>>
> As we are in the AVP Definitions, I think it is better to 
>keep some text explaining it. No ?
>
> In my understanding the local ER server only sends the Domain 
>Name which will then be used to compute keys. Maybe the type 
>DiameterIdentity is not appropriated and we should use 
>UTF8String instead. What do you think ?
>
>
>>
>> 6.2.  EAP-DSRK AVP
>>
>> [LM] this table is ok according to the current RFC 3588. I 
>don't know how to deal with it regarding the RFC3588bis...
>
>

---

From: <[email-masked]>
Date: Thu, 8 Jan 2009 21:26:09 +0100

According to the RFC 5296, it seems that it is not required to have a specific Appl-ID:

  "It is plausible that the authenticator does not know whether the peer
   supports ERP and whether the peer has performed a full EAP
   authentication through another authenticator.  The authenticator MAY
   initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
   message, and if there is no response, it will send the EAP-Request/
   Identity message.  Note that this avoids having two EAP messages in
   flight at the same time [2].  The authenticator may send the EAP-
   Initiate/Re-auth-Start message and wait for a short, locally
   configured amount of time.  If the peer does not already know, this
   message indicates to the peer that the authenticator supports ERP.
   In response to this trigger from the authenticator, the peer can
   initiate the ERP exchange by sending an EAP-Initiate/Re-auth message.
   If there is no response from the peer after the necessary
   retransmissions (see Section 6), the authenticator MUST initiate EAP
   by sending an EAP-Request message, typically the EAP-Request/Identity
   message.  Note that the authenticator may receive an EAP-Initiate/
   Re-auth message after it has sent an EAP-Request/Identity message.
   If the authenticator supports ERP, it MUST proceed with the ERP
   exchange.  When the EAP-Request/Identity times out, the authenticator
   MUST NOT close the connection if an ERP exchange is in progress or
   has already succeeded in establishing a re-authentication MSK.

   If the authenticator does not support ERP, it drops EAP-Initiate/
   Re-auth messages [2] as the EAP code of those packets is greater than
   4.  An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message
   retransmissions and fall back to EAP authentication by responding to
   EAP Request/Identity messages from the authenticator.  If the peer
   does not support ERP or if it does not have unexpired key material
   from a previous EAP authentication, it drops EAP-Initiate/
   Re-auth-Start messages.  If there is no response to the EAP-Initiate/
   Re-auth-Start message, the authenticator SHALL send an EAP Request
   message (typically EAP Request/Identity) to start EAP authentication.
   From this stage onwards, RFC 3748 rules apply.  Note that this may
   introduce some delay in starting EAP.  In some lower layers, the
   delay can be minimized or even avoided by the peer initiating EAP by
   sending messages such as EAPoL-Start in the IEEE 802.1X specification
   [10]."

Both paragraphs assume (for me) that the ERP "option" may be supported by the peer and/or the network. If none of them (or only one of them) support ERP, the fallback mechanism is full EAP authentication.
In that sense, knowing that the network supports ERP is not a pre-requisite. The minimum is to support EAP and ERP is an option available above EAP. That allows to deploy ERP above existing EAP deployment.

Does it make sense?

Best Regards,

Lionel

> De : Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Envoyé : jeudi 8 janvier 2009 13:55
> À : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; 
> Sebastien Decugis; [email-masked]
> Objet : RE: [Dime] Review of the Diameter ERP draft
> 
> One of the things I was not quite sure with the current 
> protocol design is whether a Diameter application or just a 
> bunch of AVPs are required.
> Based on the discussions a few of us when some of the HOKEY 
> specs went to the IESG / IETF Last Call I got the impression 
> that one has to define a new Diameter application (which 
> would be based on Diameter EAP) since you assume that the 
> messages are routed via a node in the local network and the 
> support for ERP has to be ensured. 
> 
> Ciao
> Hannes
> 
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >ext Julien Bournelle
> >server and AAA proxy have to be co-located to be able to rely on 
> >Diameter to transport ERP specific AVPs. This doesn't maybe preclude 
> >other architectural choices but there are outside the scope of this 
> >document. It is necessary to clarify this point in this document.
> >>
> >> - ERP support discovery:
> servers that 
> >do not understand this new AVPs. Some text should be provided to 
> >describe how the local ER server discovers that the Home EAP server 
> >doesn't support ERP and the behaviour of the local ER server in that 
> >case.
> >
> >
> here. These 
> >newly EAP packets are then carried in messages (dependent of the 
> >protocol used).
> >
> >>
> >that the local ER server  and the AAA agent are co-located, 
> to be able 
> >to rely on DEA for the transport of DSRK.  In that case, I would say 
> >something like:
> >>
> >> [LM] s/"EAP Initiate Reauth message"/"EAP-Initiate/Re-auth 
> message" 
> >which will then be used to compute keys. Maybe the type 
> >DiameterIdentity is not appropriated and we should use UTF8String 
> >instead. What do you think ?
> >
> >
> >>
> >> 6.2.  EAP-DSRK AVP
> >>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Jan 2009 09:57:53 +0200

My reading of this text is that there is a way for the peer and the authenticator to figure out whether to use EAP or ERP. 
It, however, says very little about the further routing of AAA messages in such a way that the messages traverse nodes understanding the additionally required functionality. If I understood ERP correctly then some key caching takes place in the AAA proxies and hence one wants to make sure that the messages are actually routed via these proxies.

Ciao
Hannes

>From: ext [email-masked] 
>[mailto:[email-masked]] 
>Sent: 08 January, 2009 22:26
>To: Tschofenig, Hannes (NSN - FI/Espoo); 
>[email-masked]; [email-masked]; [email-masked]
>Subject: RE: [Dime] Review of the Diameter ERP draft
>
>Both paragraphs assume (for me) that the ERP "option" may be 
>supported by the peer and/or the network. If none of them (or 
>only one of them) support ERP, the fallback mechanism is full 
>EAP authentication.
>In that sense, knowing that the network supports ERP is not a 
>pre-requisite. The minimum is to support EAP and ERP is an 
>option available above EAP. That allows to deploy ERP above 
>existing EAP deployment.
>
>Does it make sense?
>
>Best Regards,
>
>Lionel
>
>
>> À : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien 
>> Decugis; [email-masked] Objet : RE: [Dime] Review of the Diameter ERP 
>> draft
>> 
>> One of the things I was not quite sure with the current protocol 
>> design is whether a Diameter application or just a bunch of AVPs are 
>> required.
>specs went 
>> to the IESG / IETF Last Call I got the impression that one has to 
>> define a new Diameter application (which would be based on Diameter 
>> EAP) since you assume that the messages are routed via a node in the 
>> local network and the support for ERP has to be ensured.
>> 
>> Ciao
>> Hannes
>>

---

From: <[email-masked]>
Date: Fri, 9 Jan 2009 10:06:58 +0100

I understand.

However, I don't see how the use of a new appli-ID will solve this issue if you have multiple AAA proxies supporting ERP in the same visited domain. If you reach a new AAA proxy that has not yet the DSRK, it will have to contact anyway the home EAP server to retrieve this key.
For me, ERP with a local ER server will be useful for peers connected to the same EAP authenticator for a long time or if several EAP authenticators are connected to the same AAA proxy. And in the latter case, it is just an architectural issue.

BR,

Lionel

> Envoyé : vendredi 9 janvier 2009 08:58
> À : MORAND Lionel RD-CORE-ISS; [email-masked]; 
> [email-masked]; [email-masked]
> My reading of this text is that there is a way for the peer 
> and the authenticator to figure out whether to use EAP or ERP. 
> It, however, says very little about the further routing of 
> AAA messages in such a way that the messages traverse nodes 
> understanding the additionally required functionality. If I 
> understood ERP correctly then some key caching takes place in 
> the AAA proxies and hence one wants to make sure that the 
> messages are actually routed via these proxies.
> 
> Ciao
> Hannes
>  
> 
> >To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]; 
> >[email-masked]; [email-masked]
> >According to the RFC 5296, it seems that it is not required 
> to have a 
> >specific Appl-ID:
> >
> supported 
> >by the peer and/or the network. If none of them (or only one 
> of them) 
> >support ERP, the fallback mechanism is full EAP authentication.
> >pre-requisite. The minimum is to support EAP and ERP is an option 
> >available above EAP. That allows to deploy ERP above existing EAP 
> >deployment.
> >
> >Does it make sense?
> >
> >Best Regards,
> >
> >Lionel
> >
> >
> >> >>                                            |    AVP 
> Flag Rules   |

---

From: "Julien Bournelle" <[email-masked]>
Date: Fri, 9 Jan 2009 10:15:10 +0100

Hi,

> My reading of this text is that there is a way for the peer and the authenticator to figure out whether to use EAP or ERP.

 I don't see how a new App Id will help peer and authenticator to
figure out ERP support. I may miss something here.

 My understanding is that a new Appid would however help AAA entities
(authenticator, proxy, server) figure out ERP support.

> It, however, says very little about the further routing of AAA messages in such a way that the messages traverse nodes understanding the additionally required functionality. If I understood ERP cor…

 Yes, ideally, for a given peer, the same AAA proxy/local ERP server
should be contacted by authenticators. At this point, I don't see how
to ensure this.

 Regards,

 Julien

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Jan 2009 12:53:50 +0200

Good to have you guys to figure out how all this is going to work. 

Ciao
Hannes

PS: I will have to re-read the ERP spec to come to my own conclusion on this issue.  

>Sent: 09 January, 2009 11:07
>However, I don't see how the use of a new appli-ID will solve 
>this issue if you have multiple AAA proxies supporting ERP in 
>the same visited domain. If you reach a new AAA proxy that has 
>not yet the DSRK, it will have to contact anyway the home EAP 
>server to retrieve this key.
>For me, ERP with a local ER server will be useful for peers 
>connected to the same EAP authenticator for a long time or if 
>several EAP authenticators are connected to the same AAA 
>proxy. And in the latter case, it is just an architectural issue.
>
>BR,
>
>Lionel
>
>
>> Envoyé : vendredi 9 janvier 2009 08:58 À : MORAND Lionel 
>RD-CORE-ISS; 
>> My reading of this text is that there is a way for the peer and the 
>> authenticator to figure out whether to use EAP or ERP.
>> It, however, says very little about the further routing of AAA 
>> messages in such a way that the messages traverse nodes 
>understanding 
>> the additionally required functionality. If I understood ERP 
>correctly 
>> then some key caching takes place in the AAA proxies and hence one 
>> wants to make sure that the messages are actually routed via these 
>> proxies.
>> 
>> Ciao
>> Hannes
>>  
>> 
>> >> Envoyé : jeudi 8 janvier 2009 13:55 À : ext Julien Bournelle; 
>> >> MORAND Lionel RD-CORE-ISS; Sebastien Decugis; 
>[email-masked] Objet : 
>> >> RE: [Dime] Review of the
>> Diameter ERP
>> >> draft
>> >>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 09 Jan 2009 11:25:41 -0500

An use case for the second problem talked about in the routing design team!

---

From: Tina TSOU <[email-masked]>
Date: Sat, 10 Jan 2009 20:47:24 +0800

Hi Tom,
Thanks for your comments.
I will update the draft-tsou-dime-routing-problem-statement-01, adding  
this use case for the 2nd problem, hopefully before the design team  
meeting next Thursday.
The design team discussion could be found in
http://groups.google.com/group/diameter-routing?hl=en

B. R.
Tina
Messengers:

MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU     
Jabber: [email-masked]    Google talk: [email-masked]

+86-755-28971872 (Office)    +86-13922884380(Mobile)

On Jan 10, 2009, at 12:25 AM, Tom Taylor wrote:

>>> My reading of this text is that there is a way for the peer and  
>>> the authenticator to figure out whether to use EAP or ERP.
>>> understood ERP correctly then some key caching takes place in the  
>>> AAA proxies and hence one wants to make sure that the messages are  
>>> actually routed via these proxies.
>>>>>> Name
>>>>>>>                                           |    AVP Flag  
>>>>>>> Rules   |

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 10 Jan 2009 15:14:45 +0200

Hi Tom, Hi Tina,  

I believe you are misunderstanding the Diameter ERP usage (could also be
me). 

We are not talking about "route-pinning" AAA routing but rather whether the
definition of AVPs is sufficient for the design or whether a Diameter
application. 

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Tina TSOU
>Sent: 10 January, 2009 14:47
>To: Tom Taylor
>Cc: Julien Bournelle; Tschofenig, Hannes (NSN - FI/Espoo); 
>[email-masked]; [email-masked]
>I will update the 
>draft-tsou-dime-routing-problem-statement-01, adding this use 
>case for the 2nd problem, hopefully before the design team 
>meeting next Thursday.
>> An use case for the second problem talked about in the 
>routing design 
>> team!
>>
>> Julien Bournelle wrote:
>>> Hi,
>>>>> According to the RFC 5296, it seems that it is not 
>required to have 
>>>>> a specific Appl-ID:
>>>>>
>>>>> "It is plausible that the authenticator does not know whether the 
>>>>> peer  supports ERP and whether the peer has performed a full EAP  
>>>>> authentication through another authenticator.  The authenticator 
>>>>> MAY  initiate the ERP exchange by sending the 
>EAP-Initiate/Re-auth- 
>>>>> Start  message, and if there is no response, it will send 
>the EAP- 
>>>>> Request/  Identity message.  Note that this avoids having two EAP 
>>>>> messages in  flight at the same time [2].  The authenticator may 
>>>>> send the EAP-  Initiate/Re-auth-Start message and wait 
>for a short, 
>>>>> locally  configured amount of time.  If the peer does not already 
>>>>> know, this  message indicates to the peer that the authenticator 
>>>>> supports ERP.
>>>>> retransmissions (see Section 6), the authenticator MUST initiate 
>>>>> EAP  by sending an EAP-Request message, typically the 
>>>>> EAP-Request/Identity  message.  Note that the authenticator may 
>>>>> receive an EAP-Initiate/  Re-auth message after it has sent an 
>>>>> EAP-Request/Identity message.
>>>>> exchange.  When the EAP-Request/Identity times out, the 
>>>>> authenticator  MUST NOT close the connection if an ERP 
>exchange is 
>>>>> in progress or  has already succeeded in establishing a 
>>>>> re-authentication MSK.
>>>>>
>>>>> Re-auth messages [2] as the EAP code of those packets is greater 
>>>>> than  4.  An ERP-capable peer will exhaust the 
>EAP-Initiate/Re-auth 
>>>>> message  retransmissions and fall back to EAP authentication by 
>>>>> responding to  EAP Request/Identity messages from the 
>>>>> authenticator.  If the peer  does not support ERP or if 
>it does not 
>>>>> have unexpired key material  from a previous EAP 
>authentication, it 
>>>>> drops EAP-Initiate/  Re-auth-Start messages.  If there is no 
>>>>> response to the EAP-Initiate/  Re-auth-Start message, the 
>>>>> authenticator SHALL send an EAP Request  message (typically EAP 
>>>>> Request/Identity) to start EAP authentication.
>>>>> delay can be minimized or even avoided by the peer initiating EAP 
>>>>> by  sending messages such as EAPoL-Start in the IEEE 802.1X 
>>>>> specification  [10]."
>>>>>
>>>>> supported by the peer and/or the network. If none of them 
>(or only 
>>>>> one of them) support ERP, the fallback mechanism is full EAP 
>>>>> authentication.
>[email-masked] Objet 
>>>>>> : RE: [Dime] Review of the Diameter ERP draft
>>>>>>
>>>>>> design is whether a Diameter application or just a bunch of AVPs 
>>>>>> are required.
>>>>>> EAP) since you assume that the messages are routed via a node in 
>>>>>> the local network and the support for ERP has to be ensured.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>> other architectural choices but there are outside the scope of 
>>>>>>> this document. It is necessary to clarify this point in this 
>>>>>>> document.
>>>>>>>> - ERP support discovery:
>>>>>>> describe how the local ER server discovers that the Home EAP 
>>>>>>> server doesn't support ERP and the behaviour of the local ER
>>>>> server in that
>>>>>>> case.
>>>>>>>
>>>>>>>
>>>>>>>>  This document specifies the reuse of  Diameter EAP 
>application 
>>>>>>>> to carry these new EAP messages.
>>>>>>>>  Alternatively, the NAS may send an EAP  Initiate Reauth-Start 
>>>>>>>> message to the peer to trigger
>>>>> the start of
>>>>>>>>  server MUST encapsulate the EAP-Finish/Re-auth message within 
>>>>>>>> an  EAP-Payload AVP of a Diameter EAP-Answer message.
> initial 
>>>>>>>> EAP exchange (implicit bootstrapping) or in an ERP  
>>>>>>>>  MUST send the DSRK (or send a failure result) when it 
>receives 
>>>>>>>> a  valid Diameter EAP-Request message containing an
>>>>>>> EAP-DSRK-Request AVP
>>>>>>>>  server for a particular session.  Second, it conveys 
>>>>>>>> information  about the domain and ER server identity to the
>>>>>> Diameter/EAP server.
>--~--~---------~--~----~------------~-------~--~----~
>You received this message because you are subscribed to the 
>Google Groups "diameter-routing" group.
>To post to this group, send email to 
>[email-masked] To unsubscribe from this 
>group, send email to [email-masked]
>For more options, visit this group at 
>-~----------~----~----~----~------~----~------~--~---
>

---

From: Tina TSOU <[email-masked]>
Date: Sat, 10 Jan 2009 22:38:30 +0800

Hi Hannes,
Al right, if Tom does not have clarification to your comments, I will  
not add it to draft-tsou-dime-routing-problem-statement-01.
Anyway, other technical clarification needs to be added for problem 2.  
I will try to fix it before next DT meeting on next Thursday.

B. R.
Tina
Messengers:

---

From: Tom Taylor <[email-masked]>
Date: Sat, 10 Jan 2009 09:51:48 -0500

Hannes, you have a specific solution in mind, and you have been trying to convey 
it to the others in this discussion. However, the problem as Julien states it 
(in the excerpted text below) can't be solved simply by defining a new 
application, because there could be more than one Diameter entity in a given 
netwoprk that supports that application.

> definition of AVPs is sufficient for the design or whether a Diameter

...

>>>> should be contacted by authenticators. At this point, I 

...

---

From: Tina TSOU <[email-masked]>
Date: Sun, 11 Jan 2009 10:17:33 +0800

Hi all,
Tom's clarification seems reasonable.
Should I add "the problem as Julien states it can't be solved simply  
by defining a new application, because there could be more than one  
Diameter entity in a given netwoprk that supports that application" to  
one of the use cases of problem 2 in draft-tsou-dime-routing-problem- 
statement-01?

B. R.
Tina
Messengers:

On Jan 10, 2009, at 10:51 PM, Tom Taylor wrote:

> Hannes, you have a specific solution in mind, and you have been  
> trying to convey it to the others in this discussion. However, the  
> problem as Julien states it (in the excerpted text below) can't be  
> solved simply by defining a new application, because there could be  
> more than one Diameter entity in a given netwoprk that supports that  
> application.
>
> Hannes Tschofenig wrote:
>> Hi Tom, Hi Tina,  I believe you are misunderstanding the Diameter  
>> ERP usage (could also be
>> me). We are not talking about "route-pinning" AAA routing but  
>> rather whether the
>> application. Ciao
>>>>> Yes, ideally, for a given peer, the same AAA proxy/local ERP  
>>>>> server should be contacted by authenticators. At this point, I
>>> don't see how
>>>>> to ensure this.
>>>>> Regards,
>>>>> Julien
>
> ...

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 10 Jan 2009 18:54:49 -0800

> it to the others in this discussion. 

As, apparently, do you ;-).

> However, the problem as Julien
> states it

ERX & hokey traffic can't just be sent to any random Diameter entity, it
needs to go to a hokey server.  Whether that entity speaks RADIUS, Diameter
or something else is irrelevant from the POV of service discovery & routing.

> server

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 11 Jan 2009 19:09:41 +0200

Tom and Julien, maybe you are right. You might know ERP better than I
do. 

Give me some time to re-read the HOKEY documents to provide a solid
analysis. 
Before doing that I do, however, need to focus my time on finishing the
RFC3588bis document. 

Ciao
Hannes

>From: ext Tom Taylor [mailto:[email-masked]] 
>Sent: 10 January, 2009 16:52
>To: Hannes Tschofenig
>Cc: [email-masked]; 'Julien Bournelle'; 
>Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>Hannes, you have a specific solution in mind, and you have 
>been trying to convey it to the others in this discussion. 
>However, the problem as Julien states it (in the excerpted 
>text below) can't be solved simply by defining a new 
>application, because there could be more than one Diameter 
>entity in a given netwoprk that supports that application.
>
>Hannes Tschofenig wrote:
>> Hi Tom, Hi Tina,
>> 
>> I believe you are misunderstanding the Diameter ERP usage 
>(could also 
>> be me).
>> 
>> We are not talking about "route-pinning" AAA routing but rather 
>> whether the definition of AVPs is sufficient for the design 
>or whether 
>> a Diameter application.
>> 
>> Ciao
>> Hannes
>
>...
>