Mercurial > hg > ietf
changeset 2:8c7a9fc32b39
Work document for interoperability issues between peer and authenticator with ERP.
author | Sebastien Decugis <sdecugis@nict.go.jp> |
---|---|
date | Tue, 17 Mar 2009 14:19:47 +0900 |
parents | 7a9e3b46c8c8 |
children | e7bcb9ee39b5 |
files | peer and authenticator.txt |
diffstat | 1 files changed, 208 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /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. +