[Dime] Remaining issues of draft-ietf-dime-erp-06

[wuqin 53375 <[e-mail]>]

Hi,
I have read the version 06 of draft-ietf-dime-erp and found a number of Editor notes in the form of QUESTION or PROBLEM
that still needs to clean up, here are my editorial comments and suggestions on this draft:
- Section 4, Paragraph 4: "this ERP/DER message reachs this server" -> "this ERP/DER message reaches this server"
- Section 4, Paragraph 6: "an error DIAMETER_UNABLE_TO_DELIVER is generated as specified in [RFC3588] and returned to the authenticator." 

--------------------------------------------------------------------------------

[Qin Wu]: It is not clear who send this error message to the authenticator that sends ERP/DER message?

I think it is home EAP server that send error message.



- Section 4, Paragraph 9: "the ER server should not possess the root key in its local database. In this case, the ER server acts as a proxy" -> "the ER server may or may not possess the root key in its local database.  If the ER server possess the root key,the ER server should respond directly to the peer that initiate ERP exchange otherwise,the ER server acts as a proxy"



- Section 5.1, Paragraph 1: "the server is immediatly available for re-authentication of the peer"->"the server is immediately available for re-authentication of the peer"



- Section 5.2,Paragraph 2: 

     " Change the content of Application-Auth-Id accordingly.

 

      QUESTION: Is it better to leave it unmodified, so that the server

      can easily differenciate between ERP and standard EAP message?

     "


--------------------------------------------------------------------------------

 [Qin Wu]:Of Application-Auth-Id AVP is included, I think it will be better to change Application-Auth-Id to get 

consistent with the value of Application ID in the message header.



- Section 5.2, Paragraph 2:

"

      Add the ERP-RK-Request AVP, which contains the name of the domain

      where the ER server is located.

 

      PROBLEM: Add the Destination-Host AVP to reach the appropriate

      Diameter EAP server in case there is more than one in destination

      domain, the one with the EMSK.  How does the ER server know this

      information?  Or can we require that all Diameter EAP servers can

      be used interchangeably for this purpose?

"


--------------------------------------------------------------------------------

 [Qin WU]: What about the case where  there are one ER server located in visited domain and one ER server

 located in the home domain, which domain name should be included in the ERP-RK-Request message?

To fix this, we have two ways:

1.       only allow the ER server that is close to the client to add the name of the domain where the ER server is located to the Diameter message.

2.       Only allow one ER server between the peer and home EAP server,i.e., either local ER server or home ER server.



- Section 5.2, Paragraph 2:

"

      PROBLEM: Add the Destination-Host AVP to reach the appropriate

      Diameter EAP server in case there is more than one in destination

      domain, the one with the EMSK.  How does the ER server know this

      information?  Or can we require that all Diameter EAP servers can

      be used interchangeably for this purpose?

"

[Qin Wu]:It seems to me the ER server doesn’t know Destination-Host AVP that contain the Diameter EAP server unless 

the Diameter EAP server told the ER server during Root key transportation in the bootstrapping phase.



- Section 5.3, Paragraph 4:



"

In particular, it includes the Domain- Name TLV

   attribute with the content from the ERP-Realm AVP.

"


--------------------------------------------------------------------------------

 [Qin Wu]It is not clear which message include Domain Name TLV?

I guess the rationale here is to guarantee that the Diameter message routing to and from the server go through the same path. If in such case,

this sentence should be placed behind the last sentence.

"

- Section 6,Paragraph 4:"It creates a Diameter EAP Request following the general process of Diameter EAP [RFC4072]"

-> "It creates a Diameter ERP/DER message following the general process of Diameter EAP [RFC4072]"



- Section 6, Paragraph 4:
"
The Auth-Request-Type AVP content is set to [Editor's note: FFS].

"


--------------------------------------------------------------------------------

 [Qin WU]If we decouple authorization from authentication and leave authorization out of scope, the Auth-Request-Type should be always authenticate_only.

If we need to discuss how to deal with authorization AVP, the Auth_request-Type can be authoriz_only or authorize_authenticate.



- Section 12, Paragraph 2:

"

 

   FFS: Do we really respect these security considerations with the

   mechanism we describe here?  Is it safe to use ERP-RK-Request & Key

   AVPs?  What is the worst case?  For example if a domain tricks the

   peer into beliving it is located in a different domain?



--------------------------------------------------------------------------------

 [Qin WU]:Good question, I think at least RFC3588 or bis and RFC4072 should apply here. 

But I am not sure RFC5247 or RFC5295 should apply here.

As described in RFC5296, in order to protect the content delivered in the EAP-Finish to 

the local ER server, the home ER server need to verify the validity of local ER server and 

told the peer using authorization Indication TLV.

"



- Section 12, Paragraph 3:

"

   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.

 

   QUESTION: What does this paragraph actually mean?


--------------------------------------------------------------------------------

 [Qin WU]:I guess the motivation to write this paragraph is to deal with authorization issue.

 If we agree authorization issue should be addressed in this document and Session-Id is part 

of Channel Binding information, this paragraph may be relevant.

"



Regards!

-Qin



******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************