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

[Glen Zorn (glenzorn]

> 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. 

[gwz] 
Section 5.3 is muddled at best, not clearly delineating RADIUS & Diameter &
lumping them together as "AAA" when convenient (but not necessarily
appropriate) & making statements about RADIUS that are impossible to
reconcile with the actual protocol.
[/gwz]

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.

[gwz] 
This appears to be a Standards Track document, purporting to use standards
language as defined in RFC 2119.  RFC 2119 says about the "MUST" keyword:

   1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
      definition is an absolute requirement of the specification.

Maybe its just me, but I'm having more than a little trouble reconciling
this definition with your statement that "The purpose of the document is not
to dictate...".  It's easier to see the connection between your description
of the document's purpose, what it actually says & the following (also from
RFC 2119):

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability."

If the purpose is actually documentation then at the very least the intended
status of the draft should be changed to Informational.
[/gwz]

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.

[gwz] OK [/gwz]

> 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.

[gwz] 
No offense, but that is utter & total nonsense: we are not talking about
what I tell Acme about what you did or didn't do, we are talking about the
effects of my lying to you about my name.  Far from answering my question,
you prove my point: the verification of my identity has nothing to do with
my ability or tendency to modify your data or misrepresent your actions
_later_ in the session.  
[/gwz]

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

[gwz] 
If channel bindings are to be required, it does seem like their actual
utility (& the actual "potential for causing harm" in their absence) is
strongly related to this document.
[/gwz] 

Jari