Hi Sam,
Many thanks for the opportunity to comment on the proposed text before
approval.
I do have concerns with the proposed text. Some of the new requirements
are overly burdensome. In other places, it is not clear what is expected.
Some notes below:
Sam Hartman wrote:
Hi, folks. The following last call comment was received and based on
discussion the draft was updated. This comment never seems to have
made it to the ietf list though.
The following text was added to address the comment. Please confirm
that this text addresses the comment and that from the following text
it is clear that these requirements prohibit authenticator
impersonination:
Peer and authenticator authorization
Peer and authenticator authorization MUST be performed. These
entities MUST demonstrate possession of the appropriate keying
material, without disclosing it. Authorization is REQUIRED
whenever a peer associates with a new authenticator. The
authorization checking prevents an elevation of privilege
attack, and it ensures that an unauthorized authenticator is
detected.
I must say I do not fully understand the paragraph above. I took a
quick look at 2906 and that RFC has a more nuanced take on
authorization. If we are going to require something we need to be more
specific.
Specifically, what does it mean to say "Peer and authenticator
authorization MUST be performed?" Who is authorizing whom to do what?
Is proof of possession of keying material proof of authorization? Not
according to the text below (on the 4-way exchange etc.).
Authorizations SHOULD be synchronized between the peer, NAS,
and backend authentication server. Once the AAA key management
protocol exchanges are complete, all of these parties should
hold a common view of the authorizations associated the other
parties.
This is better. (Nit: There is an editorial mistake in the last sentence.)
In addition to authenticating all parties, key management
protocols need to demonstrate that the parties are authorized
to possess keying material.
What does this mean? How do key management protocols demonstrate that
the parties are authorized to possess keying material? Does this mean
that key management protocols must facilitate carrying authorization
information? Or must carry authorization information? Or that a party
requesting a key must prove that it is authorized to possess that keying
material?
Note that proof of possession of
keying material does not necessarily prove authorization to
hold that keying material. For example, within an IEEE
802.11i, the 4-way handshake demonstrates that both the peer
and authenticator possess the same EAP keying material.
However, by itself, this possession proof does not demonstrate
that the authenticator was authorized by the backend
authentication server to possess that keying material.
The example is helpful, but are we then saying that 802.11i and the
4-way handshake are non-compliant? Or put differently, how do we fix
the 4-way handshake so that the authenticator can prove to the peer that
it was authorized to possess the keying material it has? Does the peer
need to prove to the authenticator of its authorization to hold the same
keying material?
As
noted in RFC 3579 in section 4.3.7, where AAA proxies are
present, it is possible for one authenticator to impersonate
another, unless each link in the AAA chain implements checks
against impersonation. Even with these checks in place, an
authenticator may still claim different identities to the peer
and the backend authentication server. As described in RFC
3748 in section 7.15, channel binding is required to enable the
peer to verify that the authenticator claim of identity is both
consistent and correct.
Consistent sure, but why is correctness of the claim of identity
necessary? Put another way, is there a way to solve the problem of the
authenticator providing the same incorrect identity to the peer and the
server. I think there is in a number of usage scenarios, and therefore
propose that the requirement on correctness should be relaxed. More
specifically, I think we should stick to the guidance level of RFC 3579.
If no serious objections are raised, I'll finally be able to approve
this draft next week
Once again thanks for the opportunity. Please do consider this as an
objection to the new text.
regards,
Lakshminath
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf