eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying

[Jari Arkko (jari.arkko]

Glen,

> In Section 5.3, change:
>
> OLD:
> Authentication mechanisms MUST maintain the confidentiality of any
> secret values used in the authentication process.
> NEW:
> Each party in the AAA key management protocol MUST be
> authenticated to the other parties with whom they communicate.
>
> [gwz] 
> This wording would seem to preclude the use of any real-life AAA
> infrastructure in the "AAA key management protocol" since in a chain of
> RADIUS proxies (or Diameter agents) authentication is pairwise, not
> end-to-end.
> [/gwz]
>   
By the way, the substance of the document was not changed, as the added
statement appeared earlier in the document but in another form.

In any case, the implications of this requirement are discussed in later
in Section 5.3, along with what the situation is in real-life AAA,
what remedies exist, what the consequences may be if the
requirement is not followed, etc. The purpose of the document
is not to dictate perfect security or legitimize what we have
out there. The purpose of the document is to document what
the security implications of current practices and/or possible
remedies are, as well as to document what the requirements
are if truly fully secure system is desired even against attacks
from the roaming intermediaries. And I think the document
does that.

Having said that, I actually agree that this particular requirement
(which by the way comes out of RFC 4962) is too strong, and
that in practice people will rely on intermediaries; there are
many other threats that are much more interesting in practice
than this is. However, we are not in a position in the process
where we should start re-evaluating decisions that the WG
took earlier. In addition, the document is correct in stating that
if the proxies are aware of the keying material, certain
vulnerabilities exist.

> Authentication mechanisms MUST maintain the confidentiality of
> any secret values used in the authentication process.
>
> In Section 5.5, change:
>
> OLD:
> 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.
> NEW:
> Once the AAA key management
> protocol exchanges are complete, all of these parties should
> hold a common view of the authorizations associated with the
> other parties.
>
> [gwz] No change? [/gwz]
>   

Editorial change, addition of the word "with". This was a change
in RFC 4962 in RFC Editor stage, and we're aligning to that.

> and also
>
> OLD:
> As described in [RFC3748]
> Section 7.15, channel binding enables the peer to verify that the
> authenticator claim of identity is both consistent and correct.
> NEW:
> As described in [RFC3748]
> 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.
>
>
> [gwz] 
> Except, of course, in cases of collusion between members of the
> authentication chain.

This text comes from RFC 4962, not the document under consideration.

In any case, the statement is not about an absolute truth of the claim,
but rather the truth of the claim with respect to the entity the peer
trusts i.e. the server. Without channel bindings, an authenticator can
claim X to peer and Y to the server. With channel bindings, X has to be
equal to Y or otherwise an error will be detected.

So it is true that collusion between the authenticator and the server
makes it possible that the peer gets wrong information.

> BTW (I'll ask this question just one more time on the
> off-chance that I'll get a reasonable answer), what, exactly does this buy
> us (assuming no collusion)?  To use a very simple example from real life
> (what a concept!): if I prove my identity to you (even with several pieces
> of government-approved ID), what does that tell you about my basic honesty?
> I might just kill you for your wristwatch 30 seconds later.  
>   
It tells you nothing about the honesty. But it tells me that your identity
is correct.

But lets take a more useful example. Your work in the sales of Acme Inc
with whom I have a contract with. I authenticate myself to Acme via you,
and you and I agree that you sell me a watch, for which Acme will bill
me later. However, you tell Acme that a car was sold instead. I get a
bigger bill. If channel bindings had been in place, Acme would have
been able to verify that your story and my story did not add up.

In any case, this issue does not seem to be related to the document
in hand.

Jari