Reviewing the document, it looks very good overall. I have a few
comments and questions about Sections 1 through 4. The later sections
will be reviewed in a separate message.
Section 2:
Defines a number of terms, but not AAA server, which is first
referenced in Section 3.1. Similarly for AAA proxy.
It should also define "key lifetime", which is a concept used multiple
times, but not defined.
Section 3.1, Figure 1.
The diagram could be clarified to make it obvious that it is one
diagram split in two for space reasons. e.g. having linking notes
between the different portions in the first half and second half.
When the peer subsequently identifies a target authenticator that
supports EAP re-authentication, it performs an ERP exchange, as shown
in Figure 1 as well; the exchange itself may happen when the peer
attaches to a new authenticator supporting EAP re-authentication, or
prior to attachment. The peer initiates ERP by itself; ...
Figure 1 does not appear to show the peer initiating an ERP exchange.
How does the peer advertise ERP capability?
I am also unclear as to how the EAP exchange in Figure 1 will work
with existing implementations. The Reauth-Start message at the top of
the second half of the diagram is unsolicited by the peer.
... hence the
authenticator initiation of the ERP exchange may require the
authenticator to send both the EAP-Request/Identity and EAP-Initiate/
Re-auth-Start messages.
Have existing EAP peer implementations been validated to work under
these assumptions? i.e. will they break? Will they see "unexpected"
EAP messages or content, and reject or discard the response?
We introduce two new codes to EAP: EAP-Initiate and EAP-Finish. The
peer sends an EAP-Initiate/Re-auth message that includes the Peer-ID
or a temporary NAI based on the rIKname, and a sequence number for
replay protection. ...
When does the peer send these messages? Under what circumstances?
... The message is
routed using the NAI in the rIKname-NAI [4], field and if that is not
present, it is routed using the NAI in the Peer-ID. ...
Routed to where? This is the first mention of "routing" in the
document. Is this routing related to the common practice of routing AAA
requests by NAI? Do ERP servers have a routing relationship? If so,
how does it interact with AAA routing?
... Ongoing work in [10] describes an additional key
distribution protocol that can be used to transport the rRK from an
EAP server to one of many different ER servers that share a AAA trust
relationship with the EAP server.
This work would appear to be fairly core to the solution. EAP servers
are commonly deployed in conjunction with AAA servers, and interact with
AAA proxies. Can any of that discussion be added to this document? As
it stands, the document is unclear as to interaction between ERP and AAA
protocols.
In an ERP bootstrap exchange, the peer may request the rRK lifetime
to be sent to it. If so, the ER server sends the lifetime along with
the EAP-Finish/Re-auth message.
This is the first mention that they keys may have a lifetime.
I would suggest always sending the key lifetime to the peer. It is a
small amount of data, and is useful for the peer to know. i.e. there
should be strong motivations for *not* sending the key lifetime.
Section 3.2
The defined ER extensions allow executing the ERP with a local ER
server that may be topologically closer to the authenticator. ...
I'm not sure what this means, because the previous text does not
discuss network topologies.
... The
local ER server may be collocated with a local AAA server.
I think this should be "co-located".
As shown in Figure 2, the local ER server may be present in the path
of the full EAP exchange (e.g., this may be one of the AAA entities,
such as AAA proxies, in the path between the authenticator and the
home EAP server of the peer). ...
This is the first mention of AAA proxies in this document. There is
no definition of AAA proxy, and no discussion of how they interact with,
or affect, ERP.
Subsequently, when the peer attaches to an authenticator within the
local domain, it may perform an ERP exchange with the local ER server
to obtain an rMSK for the new authenticator.
It would be good to mention that this process only occurs for the
lifetime of the relevant keys.
Section 4:
We define a key hierarchy for ER, rooted at the rRK, and derived as a
result of a full EAP exchange. ...
This text is unmotivated. Why is a hierarchy being defined? An
explanation should be given. Referencing the key hierarchy draft is
useful, but leaves this document without a clear problem state that the
key hierarchy solves.
The rRK is used to derive a rIK and one or more rMSKs. ...
I would suggest saying:
The rRK is used to derive a rIK, and rMSKs for one or more
authenticators. ...
This change gives motivation to the derivation of multiple rMSKs, and
ties them into specific entities in the network.
Section 4.1.1
S = rRK Label + "\0" + NULL + length
Is this string concatenation? What is NULL? How is "length" encoded?
Are there test vectors that can be used to validate these calculations?
Section 4.1.x
It would be good to note than when a key expires, it not only MUST be
removed from use, but that it should also be completely forgotten.
Section 4.1.3:
S = rIK Label + "\0" + cryptosuite + length
How is "cryptosuite" encoded?
Section 4.1.6:
S = rMSK label + "\0" + SEQ + length
The rMSK label is the 8-bit ASCII string "Re-authentication Master
Session Key(_at_)ietf(_dot_)org" and the length refers to the length of the
rMSK
in octets.
Is "length" 8 bits? 16 bits? 32 bits?
The SEQ is the sequence number sent by the peer in the EAP-Initiate/
Re-auth message.
SEQ is undefined in this document. It would be good to include a
short definition here, to avoid requiring people to read another
document to discover how to calculate 'S'.
Alan DeKok.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf