[HOKEY] Proposed changes to draft-ietf-hokey-5296bis

[Qin Wu <[e-mail]>]

Following our discussion on the list and feedback in the last IETF meeting on simplify boostrapping,  we investigate the benefit and disadvantages of 
this issue. The issue can be discussed in two aspects:
======================================================================
a. Deprecate the flag ‘B’
Pro: 
    In implicit  bootstrapping, ‘B’ flag is useless since peer will not send out ERP message; 
   In Explicit bootstrapping, ‘B’ flag can be used to trigger ERP message to go back to home domain and obtain the
   local domain name and related keying materials
Con:
    In both above cases, local ER server can decide if forward ERP message to the home domain 
    according to if the local server has keying materials for the peer.
============================================================================================
b. Mandate including both the name of the home domain and one of the local domain in ERP requests
Pro:
     the local ER server decide if respond directly to the peer by comparing the domain name in the request with its own domain name
Con:
    Need to assign two new TLVs to carry both home domain and local domain, which introduce transmission and computation complexity.
    Also the local ER server decide if respond directly to the peer by comparing the realm part of keyName-NAI with its own domain name.
============================================================================================================
Based on these analysis, my understanding is 'B' flag has its value in explicit bootstapping secario,  However if the local ER server has the valid 
key materials corresponding to the peer, it MUST be able to respond directly in the same way as the home ER server does without forwarding 
the ERP message to the home domain, even if this message contains the 'B'(bootstrapping) flag. Furthermore, if the ER authenticator has the valid
key materials corresponding to the peer and know the local domain name, it MUST also be able to repsond directly in the same way as the local ER server does.

Also I don't think it is a good idea to define two separate TLV for home domain name and local domain name and mandate including 
both the name of the home domain and one of the local domain in ERP requests. This overdesign will introduce extra transmission and computation overhead.
Instead, we can use 'B' flag, existing TLV for domain name or KeyName-NAI TLV to help local ER server to determine whether ER message should be 
forwarded to the home server.
If 'B' flag is carried in the ER message and TLV for domain name or realm name part of KeyName-NAI TLV carry home realm name, the local ER server doesn't have
keying materials, the ER message MUST be forwarded to the home server.
If 'B' flag is carried in the ER message and local ER server has keying materials corresponding to the peer, the local ER server should be able to respond to the peer directly.

So this note provides the proposed text changes to address this issue.
================================================================================
Section 5.1 the first paragraph:

Proposed new text:
 In implicit bootstrapping, the local AAA client or Agent MUST
 verify whether it has valid rMSK or rRK corresponding to the 
peer. If the local AAA client or Agent has the key materials 
corresponding to the peer, it MUST be able to respond directly 
in the same way as the home AAA server does without forwarding 
the ERP message to the home domain, 

=====================================================================================
Section 5.1 paragraph 2, bullet item 4:

Proposed new text:
Upon receipt of the EAP-Initiate/Re-auth message from a peer, 
the ERP-capable authenticator verifies whether it has local domain 
name and valid key materials corresponding to the peer. If it knows
 local domain name and valid key material corresponding to the peer, 
it MUST be able to respond directly in the same way as the home 
ER does with local domain name included. 

======================================================================================
Section 5.1, paragraph 2 bullet item 5:

Proposed new text:
 If the local ER server has the valid key materials corresponding to the peer,
 it MUST be able to respond directly in the same way as the home ER server 
does without forwarding the ERP message to the home domain, even if this 
message contains the 'B'(bootstrapping) flag.

Many thanks to Sebastien in particular for his valuabable comments.

Regards!
-Qin