Subject: Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authentication and key management in a data communication network"

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 9 Dec 2009 14:00:49 -0800

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.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 10 Dec 2009 12:51:14 +0200

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-masked] [mailto:[email-masked]] On
Behalf Of ext Bernard Aboba
	Sent: 10 December, 2009 00:01
	To: [email-masked]
	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:

	General Observations

	Looking at this document, I don't see much evidence that the
ITU-T has made an effort to incorporate the

	 

	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" 

	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

	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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Dec 2009 12:13:50 +0100

> authentication in the ITU-T would lead to some deployment or so. Hard to

  Who are the expected consumers of the document?

  Anyone can read the ITU document, but who will be paying attention to
it, and following its recommendations?

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Dec 2009 05:45:08 -0800

Thank you, Hannes.  

The motivation is now very clear -- we should interpret this document as a "requirements statement" for chartering of an ITU group devoted to "standardization" of (preferrably highly encumbered) zero knowledge based EAP method(s).