 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
3. Assumptions
This document makes the
following assumptions.
The Home EAP server of a peer that wants to use ERP is extended to support:
Cryptographic operations needed to derive the ERP root key
from
the EMSK. By deriving the ERP root key for a specific domain, the [Qin]: Since ERP root key can be derived for specific domain, I think these root key can also be derived for the same part of the home domain as the home EAP server, am I right? home EAP server implicitly authorizes the use of ERP within this domain. [Qin]: I am wondering what does the home EAP server base on to authorize the use of ERP within given domain? Isn't it enough to assume trust relationship between local domain and home domain? Diameter
operations to include this root key inside an
appropriate
AVP as defined in this document, in an answer message corresponding to a request that contained a request for this [Qin]:
s/contained/contains
material (AVP for the request also defined in this document).
(recommanded) Ability to answer a DER message with
EAP-Payload
containing an explicit bootstrapping ERP message. [Qin]:What does "(recommanded)"? recommended? Is there any missing text here? I am wondering ability to answer a DER message can be covered by Diameter operations? The Authenticator (NAS) is
extended to support:
Allow
the new ERP command codes (EAP-Initiate and EAP-Finish)
in
its EAP pass-through mode.
(optional) Send the EAP-Initiate/Re-Auth-Start message
[Qin]: I am wondering what's the difference between the first bullet and the
second bullet?
(optional) Provide the local domain name via lower layer
specific
mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.
Encapsulate ERP message and receive corresponding Diameter
answer,
as described in this document. If one of the components
does not match these assumptions, the ERP
mechanism will fail. In such situation, a full EAP authentication may be attempted as a fallback mechanism. We consider at most one
logical ER server entity in a domain. If
several physical servers are deployed for robustness, a replication mechanism must be deployed to synchronize the ERP states (root keys ) between these servers. This replication mechanism is out of the scope of this document. If several ER servers are deployed in the domain, we assume that they can be used interchangeably. [Qin] Does this mean all
the ER server in one domain can be seem as one logical ER
server? |