Re: [Dime] Review of the Diameter ERP draft

[Tina TSOU <[e-mail]>]

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:

MSN: [e-mail]   Yahoo: tina_tsou    Skype: tinaTSOU     
Jabber: [e-mail]    Google talk: [e-mail]

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





On Jan 10, 2009, at 9:14 PM, 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
>
>> -----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

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