Subject: [eap] comments on the keying draft

From: [email-masked] (Jari Arkko)
Date: Sun, 13 Jul 2003 08:26:59 +0300

Bernard,

We've take a big step forward with the new version of the keying
draft, and you summary note to the list. Thanks! I'm quite happy with
the document, though of course you mentioned some of the question
marks in your note. I also have a few comments:

1) Section 1.3, AN-Token: AAA-EAP-02 lacks the lifetime etc AVPs.

2) A related but general question. Assuming current RFC 2548 model
    and RADIUS vs. the discussion about key naming and DIAMETER keying
    work -- will the latter be backwards compatible with the former?

3) Section 2.1.2, "EAP methods MUST support creation and naming of
    EAP (Phase 1) Security Associations". All methods or just key
    generating methods need to support naming? Come to think of it,
    is there a security association if there is no keys?

4) Section 4.2, Security Services. It might be useful to point
    out here that the AN-Token protection defined later will
    require confidentiality. It looked odd to me to say confidentiality
    is optional. In fact, I have some trouble understanding
    the difference between the three first three items in this
    section vs. the AN-Token protection. Doesn't AN-Token
    protection cover everything that we need?

5) Section 4.2, Mutual Authentication. Hmm... does RADIUS
    with proxies support mutual authentication?

6) Section 4.2, Forgery Protection. The Diameter scheme
    should be listed here as well.

7) Section 4.5 "absent the TSK derivation step, EAP mutual
    authentication only proves that the authenticator is trusted
    by the backend authentication server; the identity of the
    authenticator is not confirmed". I wonder if "the authenticator"
    is shown to be trusted. I suspect that its *some* authenticator
    that must be trusted, but not necessarily the one that the
    peer is talking to. A rogue authenticator could channel the
    EAP protocol run to a real, trusted authenticator and act
    as a man-in-the-middle peer for him.

8) Section 4.5, "data object security SHOULD be used..."
    Are we back into requiring Diameter CMS? Is that really
    necessary, even if we avoid proxies?

9) Section 5.2, "impersonation detection requires DNS A/AAAA
    and PTR RRs to be properly configured". Hmm.... I wonder if
    we can use AltSubjName vs. claimed domain name checks as in
    https?

10) Section 5.3, "where PFS is implemented, compromise of
     the MSK does enable" -- a missing "not" before "enable"?

11) Section 5.3, mitigation by redirects. Still, its the
     proxy that controls the redirection. If we assume proxies
     are bad, can't proxy.foo.com redirect you to proxy2.foo.com
     instead of home.bar.com?

--Jari