In general I think the document is a good start. I think it needs some
work in a few areas
1. Section 1
- The following sentence is a bit odd:
"Here, a Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using one set of
credentials, while representing contrary information to EAP clients."
The credentials are often different, it is the service that the AAA
server expects the NAS to provide vs. what is actually provided.
"Here, the backend AAA infrastructure may expect the Network Access
Server (NAS) or pass-through authenticator to provide one set of
services, while the NAS may represent contrary service offerings to EAP
clients."
- I would prefer if referred to the general solution technique before
referencing [AAAPAY]. For example in the last paragraph:
"This document uses a process in which the EAP client provides
information about the characteristics of the service provided by the
authenticator to the AAA server protected within the EAP method,
allowing the server to verify the authenticator is providing valid
information to the peer. The server can also respond back with
additional information that could be useful for the client to decide
whether or not to continue its session with the authenticator. "AAA
Payloads" defined in [AAAPAY] proposes a mechanism to carry this
information."
2. Section 3
Channel bindings [RFC5056] seek to enforce a stronger security
relationship between the three entities, by allowing the client and
server to compare their relative perception of the authenticator's
identity in a secure channel.
[Joe] Identity is only one aspect of channel binding issues. Often the
client does not really care or know much about the authenticator
identity, it cares about the characteristics of the services provided by
the authenticator.
This document defines how to use "AAA
Payloads" [I-D.clancy-emu-aaapay] within EAP methods to implement
channel bindings.
[Joe] Here again I would prefer to reference the general technique of
communicating information with [AAAPAY] as an example.
Unlike [RFC5056], channel binding in EAP context
does not ensure binding different layers of a session but rather the
information advertized to client and authentication server by an
authenticator acting as pass-through device during an EAP session.
[Joe] It goes beyond just advertisement from the authenticator to AAA
server. The AAA server must have an expectation of what the
authenticator should provide. Without this the value of channel
bindings is greatly diminished. Since the AAA server must have an
expectation of what is provided advertisement from the authenticator to
the AAA is not necessary.
It is preferable to use this idea, rather than hashing identity
information directly into keys, for a number of reasons:
o It allows for fuzzy comparisons of entity names, rather than
requiring absolute. This can facilitate deployment and debugging.
[Joe] An example, where comparison is useful is when more than one value
for a service characteristic is valid. If the exact information is not
communicated in the AAA protocol then the AAA server needs to compare
what is provided by the EAP client with a set of valid choices. It is
also useful when you do not want things to fail, but would rather track
down the problem after the fact. I think this bullet could be reworded,
perhaps 'fuzzy' is not the best term.
o Any EAP method that provides mutual authentication and key
derivation can easily add channel binding as proposed in this
draft. On the other hand, including identities into key
derivations requires the modification of EAP methods. For
instance, many EAP methods specify how MSK and other keying
material is derived and adding channel binding by adding
identifiers would need to be specified for each method
individually.
[Joe] This is one way to achieve this, but it could also be done in the
AAA server outside the EAP method. It is more likely that channel
bindings will be exported outside a method and evaluated by the other
AAA subsystems instead of the method itself.
o Client and authentication server may communicate on different
layers with the authenticator and thus receive different
identifiers that may belong to the same device. A server may be
able to recognize which different identifiers belong to the same
device (e.g. by performing a table look up). This scenario cannot
be solved by hashing identities into keys.
[Joe] I'm not sure what this means.
3. Seciton 4
I think the discussion in this section is a little off target. There is
a trust relationship between the authenticator and the AAA. The AAA
trusts that the authenticator will provide the expected set of services
to the client. The AAA needs to know what services it expects an
authenticator to provide. This knowledge may be distributed across
several AAA servers in the case of a proxy relationship. The trust is
rooted in the authentication between AAA servers and authenticator. The
EAP client is trusting that all of this works correctly and its trust is
rooted in a relationship with the AAA server hosting the EAP Server.
The issue here is that the AAA server and client have no way to verify
correct behavior of the authenticator. This is the gap that channel
bindings is trying to fill.
The text is misleading in that at some points it suggests that the AAA
server needs to trust info2. This is only partially true since trusting
info2 would allow the authenticator to advertise whatever it wants to
both sides. Later in the text this is clarified, the AAA server needs
to have access to some information that allows it to determine if info1
and info2 are within the set of acceptable values. It is not necessary
for the AAA to receive info2 from the authenticator since it needs to
know the set of acceptable values. It may help in some schemes for the
AAA to receive what the authentication has chosen if there is more than
one element in the set of acceptable values for a particular
characteristic.
I think this document should discuss a bit more on who actually verifies
the channel bindings. While EAP carries the channel bindings the EAP
method may not be the best place to carry out this evaluation. This
would typically be done in a AAA server which has more authorization
information available to it. If there is a proxy chain the evaluation
may be done at various points in the chain so the channel binding
information needs to be communicated down the chain from the EAP server.
There probably should also be some discussion on the implications of
having the EAP server collocated with the authenticator.
I think this section could use a bit more work.
4. Section 5
The introduction described a situation where an access point advertises
a different SSID than it should be allowed to, wouldn't this be
something to include in the example?
5. Section 6
This section needs to make recommendations for requirements for EAP
methods, AAA protocols and lower layers. Something like the following:
EAP method Support - EAP methods MUST be able to carry type x of data
integrity protected from client to server. EAP methods SHOULD provide a
mechanism to carry protected data from server to client. EAP methods
MUST export channel binding data to the AAA subsystem on the EAP server.
EAP methods MUST be able to import channel binding data from the lower
layer on the EAP peer.
AAA protocol support - The AAA subsystem MUST be able to process channel
binding data returned from the EAP method. It must be possible to pass
the channel binding data in AAA attributes to proxy AAA if a proxy AAA
will need to evaluate the data. I'm pretty sure that this is not the
only consideration.
Lower Layer Support - I don't think we want to define the requirements
for every lower layer in this section or in the document. I think we
need to list some requirements as to what would make good candidates for
lower layer parameters to use as channel bindings. Indicate that there
MUST be a way to convey this in the EAP method and MUST be a way to send
it in the AAA protocol unless the channel binding can be evaluated
entirely on the AAA that hosts the EAP server (home AAA).
I think we can provide an other sections of the document such as an
appendix to detail the specifics of some lower layers. These may also
belong in a separate document(s).
Cheers,
Joe
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
