--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/peer and authenticator.txt	Tue Mar 17 14:19:47 2009 +0900
@@ -0,0 +1,208 @@
+Interoperability and deployment issues for Diameter ERP.
+Author: s.decugis
+
+I - Peer and authenticator considerations.
+
+This draft document considers all possible situations between the peer and the authenticator, 
+with regards to ERP and feature supported on each entity.
+It is based on my understanding of ERP mechanism, which is not complete, so if you see big mistakes 
+please let me know.
+In the first section, I detail the different situations that can occur for interoperability issues.
+In the second section, I explain the sequence of events that are expected to occur in the different
+combinations of situations.
+In the third section, I give my views on what needs to be changed in the design so that some of the
+problems detailed here will be avoided.
+A separate document will be written later for: II - The backend considerations (interactions between ERP and EAP)
+
+
+1. The variables.
+
+1.1. Peer.
+
+a. ERP support.
+
+The peer may or may not support the ERP feature.
+Support means being able to derive a rRK and rIK material from a EMSK, 
+or from a DSRK derived from the EMSK and local domain name.
+Support means also ability to send and receive ERP messages (new EAP codes).
+
+Notation: 
+A1 = The peer supports ERP feature. 
+A2 = The peer does not support these features.
+
+
+b. Availability of keying material.
+
+When the peer supports the ERP feature, it must also have available 
+keying material, i.e. valid EMSK, to use the feature.
+
+Notation:
+B1 = The peer has a valid EMSK from a previous EAP authentication.
+B2 = The peer doesn't have such material available.
+
+
+1.2. Authenticator.
+
+a. ERP support.
+
+An authenticator that does not support ERP feature is supposed to drop all
+ERP packets. The support of ERP feature means that the authenticator is able
+to extract the keyName-NAI from ERP message to help routing the Diameter message.
+
+In some cases, the authenticator may also understand ERP messages but have determined
+that no backend is available (configuration, capability exchange, other...) to perform
+ERP operations and therefore simply reply errors to ERP messages from the peer. The 
+benefit of this situation is that the peer does not have to retransmit and timeout the
+ERP messages. On a functional point of view, this is equivalent to the case where the
+peer does not support ERP.
+
+Notation:
+C1 = The authenticator supports ERP features.
+C2 = The authenticator does not support ERP features or always sends Failure error codes.
+
+
+b. Local domain name publication.
+
+With some lower layers, the local domain name can be advertized to the peer
+during discovery phase, while some other LL do not allow this.
+
+It is always possible to advertise the local domain name in the EAP-Initiate/Re-auth-Start
+packet as a TLV, but the peer may initiate EAP-Initiate/Re-auth exchange previously to receiving
+the packet. Both situation have the same effect (peer not knowing the local domain name).
+
+We must consider both situations.
+
+Notation:
+D1 = The authenticator advertises the local domain name through the LL or Re-Auth-Start ERP message
+D2 = The peer does not receive this name.
+
+
+
+2. Sequence of events.
+
+This section is an attempt to describe the sequence of events that will occur when
+a peer attaches to a new authenticator, in order to highlight the requirements and
+possible issues for the ERP backend.
+
+Reminder: the first step is the discovery phase. During this phase, the peer and authenticator 
+may exchange information such as: ERP support, local domain name, who will start the exchange, ...
+Then the EAP or ERP exchange occurs. It may take several echanges of messages. When
+terminated, either the (re)authentication fails, or keying material (r)MSK is available to both
+the peer and the authenticator. In the later case, a Security Association Protocol is initiated 
+and uses the keying material to establish a protected connection to the network for the peer.
+
+The following cases are considered in this section:
+         --- authenticator ---
+         |   C1    |    C2   |
+         | D1 | D2 |  D1/D2  |
+ |---------------------------|
+ | A1 B1 |  1 |  2 |         |
+ p-----------------|    5    |
+ e A1 B2 |    3    |         |
+ e---------------------------|
+ r   A2  |         4         |
+ | B1/B2 |                   |
+ |---------------------------- 
+
+
+2.1. A1, B1, C1, D1 - all conditions OK for ERP.
+
+The peer receives the domain name from the new authenticator, and has a valid EMSK available.
+It may also receive a EAP-Initiate/Re-auth-Start packet from the authenticator. If domain name
+was not received during discovery phase, the peer should wait for the EAP-Initiate/Re-auth-Start
+message to check if it contains the domain name.
+
+Thanks to the domain name received from the authenticator, the peer can determine 
+if it is attaching to its home domain or a foreign domain.
+
+The peer must determine whether to start a bootstrapping ERP exchange or a normal ERP exchange.
+
+In the case where the peer is in its home domain, bootstrapping or normal exchanges are equivalent.
+(which one should be started?)
+
+In the case where the peer is in a visited domain, a normal exchange will succeed only if the local
+ER server possesses the DSRK material corresponding to the EMSK for this session of this peer.
+This happens when:
+- a previous ERP bootstrapping exchange already occurred in this domain.
+- a full EAP authentication occurred in this domain, and implicit bootstrapping was used 
+ (how does the peer know???)
+- Alternatively, is it possible for the local ER server to request material from home ER server 
+  if it does not have the required DSRK? 
+  
+If the peer determines that a bootstrapping exchange is started, it uses the rIK derived from the EMSK to 
+protect the ERP message, and the keyName-NAI is EMSKname@homedomain. The local ER server adds a
+ERP-DSRK-Request AVP while forwarding to the home ER server. The home ER server answers and adds the DSRK
+(for the local ER server), the DS-rMSK (for the authenticator) and the domain name in the ERP message for the peer.
+The peer uses this domain name to compute DSRK, DS-rRK and DS-rMSK.
+
+If one of the conditions listed previously is matched, the peer may start a normal ERP exchange. In that case,
+the keyName-NAI is EMSKname@localdomain. The message is protected by the DS-rIK. The local ER server receives this
+request and provides a DS-rMSK to the authenticator.
+
+
+2.2. A1, B1, C1, D2 - The peer does not receive the local domain name.
+
+In this case, the peer will start an exchange with its home server. It may (should?) include the 'B' flag
+(indicating bootstrapping exchange) to discover the local domain name if any.
+
+
+2.3. A1, B2, C1 - No valid EMSK available to the peer.
+
+In this case, a full EAP authentication is started. If the peer receives a EAP-Initiate/Re-auth-Start
+from the authenticator, it ignores it and waits for a Request/Identity (how to avoid this 
+delay ??? not clear in ERP document).
+
+In the case where local domain name is received (D1), the peer can assume that this local domain
+have a DSRK available for further re-authentication, making the assumption that ERP implicit bootstrapping was used.
+
+What if no local ER server is available? The authenticator must not advertise the local domain? 
+
+
+2.4. A2 - The peer does not support ERP.
+
+In that case, the peer drops EAP-Initiate/Re-auth-Start packet if any and always uses full EAP authentication.
+Initiating ERP implicit bootstrapping in that case is just a waste of computational power (and energy)
+on the ER local and home servers. 
+
+It is not important to know what features are supported by the authenticator in that case.
+
+FFS: how to avoid implicit bootstrapping in that case? (to be "green")
+
+
+2.5. A1, C2 - Authenticator (or backend) does not support ERP.
+
+Any ERP message from the peer will be dropped or answered with failure code by the authenticator.
+As a result the peer's EAP-Initiate/Re-auth will fail and the peer should fall back to using 
+full EAP authentication.
+
+If there is a local ER server, it may start implicit bootstrapping. Note that it will re-do 
+implicit bootstrapping everytime the peer re-authenticates, using full EAP authentication each time.
+
+We have the same problem as in 2.3, the peer can not know when no local ER server is available, and therefore
+can not rely on implicit bootstrapping without more information.
+
+
+
+3. Conclusion.
+
+My conclusions with regards to the considerations from this document are as follow:
+
+- The peer should always wait for first message from the authenticator if it does not receive domain name from LL, 
+and the authenticator should always send a EAP-Initiate/Re-auth-Start message with domain-name TLV.
+
+Pro: no dependency on lower layer to provide local domain name to the peer
+Pro: reduces the number of possible situations to handle on the peer and authenticator.
+
+
+- The peer must choose between initiating normal or bootstrapping ERP exchange. We restrict normal exchanges
+to occur only after previous bootstrapping exchange in the same domain, that resulted in reception 
+of the domain name (proof that the home ER server has sent the DSRK to a local ER server) i.e. we do never rely
+on implicit bootstrapping.
+
+Pro: the peer can decide whether to do normal or bootstrapping ERP.
+Pro: no useless key derivation computation.
+Pro: allow to use different Diameter Application ID for ERP, elimitating all current constraints on Diameter routing (FFS).
+Pro: allow more flexibility in deployment scenario.
+Con: need to re-design the Diameter ERP almost from scratch (but currently it can't work anyway...)
+Con: one additional round-trip with home domain in the worst case.
+