Hi Bernard,
here is my guess of the background of all this work.
Imagine a company has worked on strong password based authentication and
key exchange protocols. That company might also believe that they have
some IPRs in this field.
Now, some folks in that company would like to get their work
standardized and they seem to think that the precondition to deployment
is a standardized solution.
So far, everything is (sort of) fine.
Then, a few "mistakes" seem to have happened.
The authors believe that they need a deeper justification for publishing
a new EAP method. (This is of course is wrong since everyone can write
an EAP method and publish it as an Informational RFC.)
They do an analysis that points into the direction that such a new
method is needed. They are probably not really interested in the
analysis activity itself (and it really takes a long time to produce a
serious analysis that might even conclude that no additional work is
needed...) because they are only interested in a particular solution,
namely their own solution. So, they produce a document and, for whatever
reason, they forget to look at most of the EAP methods that would be
relevant.
Then, they go to the ITU-T to do the analysis work. Why? Maybe they
think that a standard in the area of strong password based
authentication in the ITU-T would lead to some deployment or so. Hard to
guess the real reason.
Now, you (and others in EMU) have to review their document and provide
feedback.
Did this answer all your questions?
Ciao
Hannes
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of ext Bernard Aboba
Sent: 10 December, 2009 00:01
To: [email protected]
Subject: Re: [Emu] New Liaison Statement,"Draft revised
Recommendation ITU-T X.1034,Guideline on extensible authentication
protocol based authenticationand key management in a data communication
network"
This is a review of ITU Study Group 17, TD 0495, which
represents a revision of ITU-T X.1034. For details, see:
https://datatracker.ietf.org/documents/LIAISON/file714.pdf
General Observations
Looking at this document, I don't see much evidence that the
ITU-T has made an effort to incorporate the
feedback that EMU provided during the last review:
https://datatracker.ietf.org/liaison/470/
This document is out of date, given that it doesn't reflect EAP
developments over the last 5+ years. Looking
through the reference section, there are still references to RFC
2284 (instead of RFC 3748), and no references to later
EAP-related documents including RFC 4851, RFC 5247, RFC 5296,
etc. Those references that are provided are frequently
out of date, represent expired or incorrect versions, etc.
Even the references to IEEE 802.11 are years out of date.
The problem goes deeper than just the references, though. In
the past 5 years, we have seen development of quite a
few new EAP methods, new approaches to key management, new
applications lower layers incorporating EAP, etc.
We have also see organizations such as NIST (with 800-120)
providing in-depth security analyses.
Given all of this new activity, the most basic question that
this document raises for me is "What unique value is this
document attempting to provide above and beyond what the IETF,
IEEE 802, NIST and other groups are already
doing?"
After reading this document, I still didn't have a clear idea of
the goals and objectives.
One possible answer to the question lies in Table 1, which
attempts to classify EAP methods in terms of their "levels of security"
(fundamental, middle-level, high-level).
However, I'm not clear what value this table adds beyond what is
already in NIST 800-120, RFC 4017 or other documents.
In fact, one might argue that it muddies the waters since a
number of fundamental security properties such as Authorization
and Unique Naming are not listed as only recommended or
optional, whereas these are treated as not as method properties
but as fundamental properties of the EAP/AAA system as described
in RFC 3748, 4296 and RFC 5247.
Another possibility lies in the general description of the
security properties of EAP. However, in the last five years we have
seen many, many studies of this published none of which are
referenced in the document. This includes formal analyses
(e.g. The Stanford analysis of IEEE 802.11 security, by John
Mitchell's team, work in Bill Arbaugh's group, etc.), NIST
800-120, RFC 4296, 5247, etc.
Of course, we have also seen extensions to the EAP model
introduced in RFC 5296. This is also not described in the
document.
Not only are all these aspects not referenced or described, but
in numerous places the document uses terminology
specific to IEEE 802. For example, the document discusses
"types of PTK", and "group key handshake". Non-IEEE 802
technologies typically don't use the term "PTK", and IEEE
802.1X-REV does not include a "group key handshake".
Moreover the "general flow of key management" described in
Section 8.4 is not general at all, since this does not
describe the lower layer key management used in IKEv2 or IEEE
802.16.
Moving on to Table I.1, the document evaluates EAP MD5 (does
anyone care about this anymore?), EAP SRP (long abandoned)
against a series of critieria. If this table is worth including
at all, it's worth making the effort to bring it up to date.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
