Re: [Dime] Review of the Diameter ERP draft

[Tina TSOU <[e-mail]>]

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: [e-mail]   Yahoo: tina_tsou    Skype: tinaTSOU     
Jabber: [e-mail]    Google talk: [e-mail]

[phone] (Office)    [phone](Mobile)







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

> An use case for the second problem talked about in the routing  
> design team!
>
> Julien Bournelle wrote:
>> Hi,
>> On Fri, Jan 9, 2009 at 8:57 AM, Tschofenig, Hannes (NSN - FI/Espoo)
>> <[e-mail]> 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.
>> 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 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.
>> 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
>>> Ciao
>>> Hannes
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext [e-mail]
>>>> [mailto:[e-mail]]
>>>> Sent: 08 January, 2009 22:26
>>>> To: Tschofenig, Hannes (NSN - FI/Espoo);
>>>> [e-mail]; [e-mail];  
>>>> [e-mail]
>>>> Subject: RE: [Dime] Review of the Diameter ERP draft
>>>>
>>>> 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
>>>>
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Tschofenig, Hannes (NSN - FI/Espoo)
>>>>> [mailto:[e-mail]]
>>>>> Envoyé : jeudi 8 janvier 2009 13:55
>>>>> À : ext Julien Bournelle; MORAND Lionel RD-CORE-ISS; Sebastien
>>>>> Decugis; [e-mail] 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
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]]
>>>>> On Behalf Of
>>>>>> ext Julien Bournelle
>>>>>> Sent: 08 January, 2009 12:18
>>>>>> To: [e-mail]; Sebastien Decugis;
>>>>> [e-mail]
>>>>>> Subject: Re: [Dime] Review of the Diameter ERP draft
>>>>>>
>>>>>> Hi lionel,
>>>>>>
>>>>>> some comments inline.
>>>>>>
>>>>>> On Wed, Jan 7, 2009 at 12:03 PM,
>>>>>> <[e-mail]> wrote:
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> I agree with these general comments.
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>> 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
>>>>>>>  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."
>>>>>> ok
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> It may help the reader to understand the purpose of this DRSK.
>>>>>>
>>>>>>>  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
>>>>>> 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).
>>>>>>
>>>>>>>  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."
>>>>>> First paragraph is the old and second the new ?
>>>>>>
>>>>>>> ::::::::::::::
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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]."
>>>>>> ok
>>>>>>
>>>>>>>  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."
>>>>>> ok
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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 ?
>>>>>>
>>>>>>>  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?
>>>>>>
>>>>>> I think a MUST would be better. Different views ?
>>>>>>
>>>>>>> [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)
>>>>>> yes.
>>>>>>
>>>>>>>  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.
>>>>>> Agree.
>>>>>>
>>>>>>> [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.
>>>>>>
>>>>>> 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 ?
>>>>>>
>>>>>>
>>>>>>> 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..."
>>>>>> ok
>>>>>>
>>>>>>> 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...
>>>>>>
>>>>>>
>>>>>> That's indeed a good question :).
>>>>>>
>>>>>> And that's all for my comments of your comments.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> --Julien--
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime

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