Subject: [eap] hopefully final changes for draft-ietf-eap-keying

From: Jari Arkko <[email-masked]>
Date: Sun, 11 Nov 2007 11:27:12 +0200

All,

You've seen the new draft versions appear. The changes have
related to resolving issues from Charlie's secdir review and
Sam Hartman's Discuss. I believe the final changes needed to
clear Sam's Discuss are below. I hope to close the document
in the next couple of days, send mail if you see anything
alarming.

These changes relate to text alignment between RFC 4962
and this document, and how tough requirements we place on
distribution of derived keys for future applications.

In Section 1.5, change

OLD:
If the authenticator
uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and
no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in this document, confirming that keys used to protect
data are to be known only by the peer and authenticator.
NEW:
If the authenticator or backend authentication server uses a key
derivation function to derive additional keying material, it is
trusted to distribute the derived keying material
only to the appropriate party that is known to the peer, and no
other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in RFC 4962, confirming that keys used to protect
data are to be known only by the peer and authenticator.

In Section 5.1, change

OLD:
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator (NAS-Identifier) to be defined and
understood by all parties that communicate with it. Similarly, an
EAP peer MUST NOT share any keying material with another EAP peer.
NEW:
An EAP authenticator MUST NOT share any keying material with
another EAP authenticator unless it has been derived with a
key-derivation function, since if one EAP authenticator were
compromised, this would enable the compromise of keying material on
another authenticator. In order to be able to determine whether
keying material has been shared, it is necessary for the identity
of the EAP authenticator (NAS-Identifier) to be defined and
understood by all parties that communicate with it. Similarly, an
EAP peer MUST NOT share any keying material with another EAP peer
unless it has been derived with a key-derivation function.

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

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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 11 Nov 2007 15:51:40 -0800

[gwz] ... [/gwz]

In Section 5.3, change:

OLD:

[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]

In Section 5.5, change:

OLD:

[gwz] No change? [/gwz]

and also

OLD:

[gwz] 
Except, of course, in cases of collusion between members of the
authentication chain.  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.  
[/gwz]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Nov 2007 13:25:13 +0200

Glen,

> RADIUS proxies (or Diameter agents) authentication is pairwise, not
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.

> hold a common view of the authorizations associated with the

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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Nov 2007 13:27:07 +0200

FYI -- With the publication of -22 and some discussion with Bernard,
the remaining edits appear to be:

In Section 1.5, change

OLD:
If the authenticator
uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and
no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in [RFC4962], confirming that keys used to protect data
are to be known only by the peer and authenticator.
NEW:
If the authenticator or backend authentication server uses a key
derivation function to derive additional keying material, it is
trusted to distribute the derived keying material
only to the appropriate party that is known to the peer, and no
other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in RFC this document, confirming that keys used to protect
data are to be known only by the peer and authenticator.

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 08:21:51 -0800

Looking over the document, I found a statement in Section 5.5 that
was not present in -18 or in RFC 4962, which I think the WG needs
to look at:

"  Requirement: The Secure Association Protocol (phase 2) conversation
   may utilize different identifiers from the EAP conversation (phase
   1a), so that binding between the EAP and Secure Association Protocol
   identities is REQUIRED."

Since the paragraphs below this quote from RFC 4962, it seems that this
statement is intended to add something beyond what is included in RFC 4962.
However, I'm not clear what that is, exactly.

Typically, the term "binding" refers to a cryptographic binding, but no 
existing
EAP lower layer (even IKEv2) supports binding of EAP method-specific 
identities
within the Secure Association Protocol.  In fact, RFC 4718 Section 3.5 
discusses why the
Identity Payload exchange in IKEv2 may be insufficient to establish the 
binding.

EAP lower layers such as 802.11 establish the binding by requiring that the
EAP peer utilize the same MAC source address for EAP as for the 4-way 
handshake.
Since within 802.11 PMKs can only be used on a single peer interface, 
addition
of the Peer-Id to the 4-way handshake would not add much.

Given that the authorization issue is extensively discussed elsewhere, I'm 
not clear
what this statement adds.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 12 Nov 2007 09:43:23 -0800

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

[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]

[gwz] OK [/gwz]

[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]

[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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Nov 2007 23:13:33 +0200

Bernard,

>    1a), so that binding between the EAP and Secure Association Protocol

This is a statement from -18 which the WG sent forward:

   The Secure Association Protocol (phase
   2) conversation may utilize different identifiers from the EAP
   conversation (phase 1a), so that binding between the EAP and Secure
   Association Protocol identities is REQUIRED.

Which is exactly the same statement as in the current document, though
other text around it has moved around.

But I feel that we need to talk about what changes are appropriate at
this stage. The working group has worked on the document, and eventually
sent it forward to me, to Last Call and to IESG review. It is
appropriate to at this stage to respond to Last Call comments and IESG
review comments and attempt to resolve them. We're down to one. But it
is not appropriate to introduce new changes unless they truly are
critical. The document is not in the WG process anymore. In particular,
the WG has performed its review before and during WGLC; it seems clear
that for this particular issue the text shouldn't be a surprise to the WG.

I do want the WG to be involved in verifying that changes introduced due
to Last Call or IESG review are acceptable, however.

Folks, we've already at month ten in the Last Call & IESG processing,
and I really don't want this to continue much longer. If there's a
significant issue that makes the WG as a whole believe the world would
be a better place without this document, then lets pull the document
back and fix the issue. If not, we really need to move on.

My take is that there are certainly things that we could fix in the
document, but as a whole it passes my bar for PS by a good margin. It
makes no sense to tweak the document for years. The WG has sent it
forward, external and IESG reviewers have said what they have to say.
Lets ship it. If there is a need we can issue a bis, a correction, or
address some specific topic in future documents.

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 12 Nov 2007 13:30:22 -0800

[gwz] 
...

My take is that there are certainly things that we could fix in the
document, but as a whole it passes my bar for PS by a good margin. It
makes no sense to tweak the document for years. The WG has sent it
forward, external and IESG reviewers have said what they have to say.
Lets ship it. If there is a need we can issue a bis, a correction, or
address some specific topic in future documents.
[gwz] 
I'd just like to note that for the vast majority of its lifetime this
document has been either unreadable, incomprehensible or both.  I, for one,
basically despaired of fixing it & fell back on the hope that the authors
would fix it themselves; I know that I'm not alone on this.
[/gwz]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Nov 2007 23:46:23 +0200

Glen,

> status of the draft should be changed to Informational.

First, let me remind you that I actually agree with you that the
requirements are too tight. If we were to fix that, I think the
appropriate change would be to change the keywords, not the
document status. I think we need to look at the proxy issue.

However, as I said to Bernard, this is not the stage where the WG
gets to have a new discussion about what it should put to the
document. You had a last call, and the document was sent forward.
Sometimes we run into serious problems and the WG as whole
decides that they are bad enough that the document should be
pulled back and corrected. My strong recommendation is to
finish this particular multi-year project rather than let it live
any longer.

I think the proxy issue is potentially a big issue. However, here's
what I would suggest: given that the issue starts from RFC 4962's
requirements, it does not seem possible to fix it entirely within
this document. If you believe the issue is big enough, lets organize
a discussion about what the right requirements ought to be,
and revise both RFC 4962 and this RFC based on the result of that
discussion.

> strongly related to this document.

Then let us disagree. I believe there are several people who do believe
channel bindings are useful.

And again, we're not changing the document as sent from the WG
with regards to this issue. The only change on this was an misquoted
text from RFC 4962, detected during IESG review.

Jari

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 14:21:10 -0800

Is there specific text in Section 5.3.3 that you believe needs to be 
corrected?

>> strongly related to this document.

Can you point to specific text that you believe requires implementation of
Channel Bindings?

Section 1.4 appears to indicate that Channel Bindings are optional:

"EAP methods MAY also support the import and export of channel binding 
parameters."

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Nov 2007 18:35:14 -0500

I have the same concern as Dan regarding "unless it has been derived
with a key-derivation function" part in Section 5.1.  

Why do we need this relaxing text?

Yoshihiro Ohba