Re: [Dime] Review of the Diameter ERP draft

["Hannes Tschofenig" <[e-mail]>]

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

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Tina TSOU
>Sent: 10 January, 2009 14:47
>To: Tom Taylor
>Cc: Julien Bournelle; Tschofenig, Hannes (NSN - FI/Espoo); 
>[e-mail]; [e-mail]
>Subject: Re: [Dime] Review of the Diameter ERP draft
>
>
>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
>
>
>--~--~---------~--~----~------------~-------~--~----~
>You received this message because you are subscribed to the 
>Google Groups "diameter-routing" group.
>To post to this group, send email to 
>[e-mail] To unsubscribe from this 
>group, send email to [e-mail]
>For more options, visit this group at 
>http://groups.google.com/group/diameter-routing?hl=en
>-~----------~----~----~----~------~----~------~--~---
>

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