Subject: [eap] RE: Suggested work item for EAP WG Charter

From: [email-masked] (Pat R. Calhoun)
Date: Sat, 2 Mar 2002 14:22:08 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1C238.B0FD6C40
Content-Type: text/plain

> The most critical issue still confronting IEEE 802.11 TGi is how to
> accomplish  dynamic key distribution securely. TGi has done much
> good work on how to effect key distribution between the 802.11
> access point and station, but this architecture requires at least
> one key distribution from an 802.1X authentication server to the
> access point. Today this is done using RADIUS, based on ad hoc 
> techniques. These techniques cannot securely distribute a key for
> its intended  purpose. In particular, existing RADIUS techniques
> may be suitable for handing  off a key between the authentication
> server and the access point, intended for communication between
> themselves alone, but as constituted today they are insecure for
> transferring a session key intended for use between the access
> point  and the station. To become secure the key handoff has to be
> enhanced to  incorporate additional cryptographic state that can be
> used to provide assurances to all three parties involved in the
> transaction. Examples of such state are the information
> communicated among the KDC and the communicating parties in the
> Needham-Schroeder and Otway-Rees protocols.

But the EAP WG is really not the right place to be working on AAA
protocols. In fact, I would urge you to take a look at the Diameter
protocol, currently being standardized by the AAA WG. The NASREQ
application document already describes how such session keys can be
transferred to the access point in a secure fashion (using CMS as the
cryptographic protocol).

> As of now IEEE 802.11 TGi has no legitimate forum for this
> discussion. IEEE 802.11 TGi cannot solve the backend key handoff
> methodology itself, because the communication among the backend
> components is outside its scope. A second  plausible venue--IEEE
> 802.1 TGaa, chartered with fixing identified 802.1X problems--also
> lacks the necessary charter to tackle the backend. On the other
> hand, it is infeasible for TGi to finish the design of the
> handshake between the  access point and the station without
> relating this handshake to the backend key distribution, which
> cannot be done until it is defined.

Right, and I would urge folks not to attempt to tackle this in the
IEEE SDO, since it is really a L3+ problem, and work is already in
progress... What we would really like is for folks to comment on the
draft which is about to go through another WG last call.

> My fear is that if we do not find a venue for this work, we will
> squander all the  valuable work that IEEE 802.11 TGi has done to
> rectify WEP's deficiencies, and  802.11 security will remain no
> better than the tarball the 1999 version of the  802.11 standard
> has bequeathed us. The EAP WG seems a natural home for it. Please 
> consider including this work in the EAP charter, and let me know if
> there is  anything I can do to help achieve this goal.

I agree

PatC

------_=_NextPart_001_01C1C238.B0FD6C40
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Suggested work item for EAP WG Charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>-----BEGIN PGP SIGNED MESSAGE-----</FONT>
<BR><FONT SIZE=2>Hash: SHA1</FONT>
</P>

<P><FONT SIZE=2>&gt; The most critical issue still confronting IEEE 802.11 TGi is how to</FONT>
<BR><FONT SIZE=2>&gt; accomplish&nbsp; dynamic key distribution securely. TGi has done much</FONT>
<BR><FONT SIZE=2>&gt; good work on how to effect key distribution between the 802.11</FONT>
<BR><FONT SIZE=2>&gt; access point and station, but this architecture requires at least</FONT>
<BR><FONT SIZE=2>&gt; one key distribution from an 802.1X authentication server to the</FONT>
<BR><FONT SIZE=2>&gt; access point. Today this is done using RADIUS, based on ad hoc </FONT>
<BR><FONT SIZE=2>&gt; techniques. These techniques cannot securely distribute a key for</FONT>
<BR><FONT SIZE=2>&gt; its intended&nbsp; purpose. In particular, existing RADIUS techniques</FONT>
<BR><FONT SIZE=2>&gt; may be suitable for handing&nbsp; off a key between the authentication</FONT>
<BR><FONT SIZE=2>&gt; server and the access point, intended for communication between</FONT>
<BR><FONT SIZE=2>&gt; themselves alone, but as constituted today they are insecure for</FONT>
<BR><FONT SIZE=2>&gt; transferring a session key intended for use between the access</FONT>
<BR><FONT SIZE=2>&gt; point&nbsp; and the station. To become secure the key handoff has to be</FONT>
<BR><FONT SIZE=2>&gt; enhanced to&nbsp; incorporate additional cryptographic state that can be</FONT>
<BR><FONT SIZE=2>&gt; used to provide assurances to all three parties involved in the</FONT>
<BR><FONT SIZE=2>&gt; transaction. Examples of such state are the information</FONT>
<BR><FONT SIZE=2>&gt; communicated among the KDC and the communicating parties in the</FONT>
<BR><FONT SIZE=2>&gt; Needham-Schroeder and Otway-Rees protocols.</FONT>
</P>

<P><FONT SIZE=2>But the EAP WG is really not the right place to be working on AAA</FONT>
<BR><FONT SIZE=2>protocols. In fact, I would urge you to take a look at the Diameter</FONT>
<BR><FONT SIZE=2>protocol, currently being standardized by the AAA WG. The NASREQ</FONT>
<BR><FONT SIZE=2>application document already describes how such session keys can be</FONT>
<BR><FONT SIZE=2>transferred to the access point in a secure fashion (using CMS as the</FONT>
<BR><FONT SIZE=2>cryptographic protocol).</FONT>
</P>

<P><FONT SIZE=2>&gt; As of now IEEE 802.11 TGi has no legitimate forum for this</FONT>
<BR><FONT SIZE=2>&gt; discussion. IEEE 802.11 TGi cannot solve the backend key handoff</FONT>
<BR><FONT SIZE=2>&gt; methodology itself, because the communication among the backend</FONT>
<BR><FONT SIZE=2>&gt; components is outside its scope. A second&nbsp; plausible venue--IEEE</FONT>
<BR><FONT SIZE=2>&gt; 802.1 TGaa, chartered with fixing identified 802.1X problems--also</FONT>
<BR><FONT SIZE=2>&gt; lacks the necessary charter to tackle the backend. On the other</FONT>
<BR><FONT SIZE=2>&gt; hand, it is infeasible for TGi to finish the design of the</FONT>
<BR><FONT SIZE=2>&gt; handshake between the&nbsp; access point and the station without</FONT>
<BR><FONT SIZE=2>&gt; relating this handshake to the backend key distribution, which</FONT>
<BR><FONT SIZE=2>&gt; cannot be done until it is defined.</FONT>
</P>

<P><FONT SIZE=2>Right, and I would urge folks not to attempt to tackle this in the</FONT>
<BR><FONT SIZE=2>IEEE SDO, since it is really a L3+ problem, and work is already in</FONT>
<BR><FONT SIZE=2>progress... What we would really like is for folks to comment on the</FONT>
<BR><FONT SIZE=2>draft which is about to go through another WG last call.</FONT>
</P>

<P><FONT SIZE=2>&gt; My fear is that if we do not find a venue for this work, we will</FONT>
<BR><FONT SIZE=2>&gt; squander all the&nbsp; valuable work that IEEE 802.11 TGi has done to</FONT>
<BR><FONT SIZE=2>&gt; rectify WEP's deficiencies, and&nbsp; 802.11 security will remain no</FONT>
<BR><FONT SIZE=2>&gt; better than the tarball the 1999 version of the&nbsp; 802.11 standard</FONT>
<BR><FONT SIZE=2>&gt; has bequeathed us. The EAP WG seems a natural home for it. Please </FONT>
<BR><FONT SIZE=2>&gt; consider including this work in the EAP charter, and let me know if</FONT>
<BR><FONT SIZE=2>&gt; there is&nbsp; anything I can do to help achieve this goal.</FONT>
</P>

<P><FONT SIZE=2>I agree</FONT>
</P>

<P><FONT SIZE=2>PatC</FONT>
</P>

<P><FONT SIZE=2>-----BEGIN PGP SIGNATURE-----</FONT>
<BR><FONT SIZE=2>Version: PGPfreeware 7.0.3 for non-commercial use &lt;<A HREF="http://www.pgp.com" TARGET="_blank">http://www.pgp.com</A>&gt;</FONT>
</P>

<P><FONT SIZE=2>iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk</FONT>
<BR><FONT SIZE=2>KrLI6yBZv5W3diNoBGbfZ7rL</FONT>
<BR><FONT SIZE=2>=n34F</FONT>
<BR><FONT SIZE=2>-----END PGP SIGNATURE-----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C238.B0FD6C40--

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 3 Mar 2002 08:27:05 -0800 (PST)

> transferred to the access point in a secure fashion (using CMS as the

Since I assume that Jesse's assertion applies to any two-way AAA key 
distribution mechanism, it would seem to me that it would be relevant to
the NASREQ (and possibly MOBILEIP) Diameter applications, as well as
RADIUS. I have therefore filed it as an issue with the AAA-WG. 

However, in order to evaluate the claim that a three-way key distribution
mechanism is required, some additional documentation (such as an
Internet-Draft) will probably be required, describing the attacks that can
be mounted unless a change is made.

---

From: [email-masked] (Walker, Jesse)
Date: Mon, 4 Mar 2002 06:27:16 -0800

Barnard,

Yes; please put me on the agenda. How short do you need this to be? The
agenda lists only 2 hours for the entire BOF, so presumably there is not
much time.

-- Jesse

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Saturday, March 02, 2002 12:27 PM
To: Walker, Jesse; [email-masked]; [email-masked]
Cc: [email-masked]'; [email-masked]'
Subject: Re: Suggested work item for EAP WG Charter

Would you be willing/able to make a presentation to the EAP BOF at IETF
53, in order to outline the work that you feel needs to be taken on and
why? 

Some questions to answer in your presentation:

a. Are you advocating that EAP itself incorporate rekeying functionality,
rather than having this done within the 802.1X layer? 

b. Are you advocating standardization of RADIUS AVPs for key
distribution? or are you advocating development of a new EAP method? Or
something else?

c. Are there specific security weaknesses in EAP and RADIUS that you feel
need to be addressed? 

d. Are the problems you are trying to solve only relevant to 802.11, or
could they conceivably be relevant to use with other media as well? 

On Sat, 2 Mar 2002, Walker, Jesse wrote:

> Barnard and John,
> 
> Let me suggest a work item to incorporate into the EAP WG charter. This is
> the  topic of key distribution.
> 
> accomplish  dynamic key distribution securely. TGi has done much good work
> on how to effect key distribution between the 802.11 access point and
> station, but this architecture requires at least one key distribution from
> an 802.1X authentication server to the access point. Today this is done
> using RADIUS, based on ad hoc  techniques. These techniques cannot
securely
> distribute a key for its intended  purpose. In particular, existing RADIUS
> techniques may be suitable for handing  off a key between the
authentication
> server and the access point, intended for communication between themselves
> alone, but as constituted today they are insecure for transferring a
session
> key intended for use between the access point  and the station. To become
> secure the key handoff has to be enhanced to  incorporate additional
> cryptographic state that can be used to provide assurances to all three
> parties involved in the transaction. Examples of such state are the
> information communicated among the KDC and the communicating parties in
the
> As of now IEEE 802.11 TGi has no legitimate forum for this discussion.
IEEE
> 802.11 TGi cannot solve the backend key handoff methodology itself,
because
> the communication among the backend components is outside its scope. A
> second  plausible venue--IEEE 802.1 TGaa, chartered with fixing identified
> 802.1X problems--also lacks the necessary charter to tackle the backend.
On
> the other hand, it is infeasible for TGi to finish the design of the
> handshake between the  access point and the station without relating this
> handshake to the backend key distribution, which cannot be done until it
is
> defined.
> 
> My suggestion is to set this problem as a work item for the EAP WG. What I
> have in mind is the EAP WG could define an EAP encapsulation for one or
more
> three-party key distribution protocols, with an eye toward application
> within the 802.1X framework. Handshakes like what TGi is developing would
be
> incorporated into the EAP three-party protocol, so that key distribution
and
> confirmation could be dealt with uniformly across multiple environments.
> These EAP key distribution methods would not work like existing EAP
methods,
> as by necessity they require active participation by three parties instead
> of two, but such is a  fundamental security requirement for any protocol
> that calls for a trusted third  party to distribute a key to be utlized by
> two other parties as a session key. The proposal would also ask that EAP
> methods exporting keys for securing sessions  to define how they use the
EAP
> key distribution methods, so proper security analysis can verify the
> distributed keys can be traced as authorized by the EAP authentication, at
> least when used in 802.1X-like environments.
> 
> My fear is that if we do not find a venue for this work, we will squander
> all the  valuable work that IEEE 802.11 TGi has done to rectify WEP's
> deficiencies, and  802.11 security will remain no better than the tarball
> the 1999 version of the  802.11 standard has bequeathed us. The EAP WG
seems
> a natural home for it. Please  consider including this work in the EAP
> charter, and let me know if there is  anything I can do to help achieve
this
> goal.
> -- Jesse Walker

---

From: [email-masked] (Walker, Jesse)
Date: Mon, 4 Mar 2002 06:30:00 -0800

Bernard,

If there is a better place for this work, then by all means let's do it
there. I do not care where it gets done, as long as it gets done. The
problem right now is 802.11 TGi is trying to sort this out by themselves,
and it is not chartered to fix many of the things that need to get fixed.

-- Jesse

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Saturday, March 02, 2002 1:55 PM
To: Walker, Jesse
Cc: [email-masked]'; [email-masked]'
Subject: Re: Suggested work item for EAP WG Charter

I should also mention that there is already an IETF WG that is chartered
for backend authentication server work -- AAA WG. At IETF 52 there was
discussion on the NASREQ Keying AVPs. If I understand your argument below,
it is that use of these AVPs is inappropriate and should be reconsidered. 

You might take a look at:

http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-diameter-nasreq-09.txt
For a description of the keying functionality. 

securely
authentication
session
the
IEEE
because
On
is
more
be
and
methods,
EAP
seems
this

---

From: [email-masked] (Walker, Jesse)
Date: Mon, 4 Mar 2002 07:18:04 -0800

------_=_NextPart_001_01C1C38F.C7A84D40
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,
 
Your suggestion to work this within the context of DIAMETER has great merit.
My only concern with it is that RADIUS vendors fully intend to support
802.1X and 802.11, and 802.11 vendors fully intend to rely on this support.
This means that either RADIUS would need to be upgraded to accommodate the
needs of keying, or else the issue has to be brought out into the open so
that people would know not to try to deploy products in this configuration,
at least when their goal is security.
 
-- Jesse

-----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Saturday, March 02, 2002 2:22 PM
To: [email-masked]'
Subject: [eap] RE: Suggested work item for EAP WG Charter

I agree 

PatC 

-----BEGIN PGP SIGNATURE----- 
Version: PGPfreeware 7.0.3 for non-commercial use < http://www.pgp.com
<http://www.pgp.com> > 

iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk 
KrLI6yBZv5W3diNoBGbfZ7rL 
=n34F 
-----END PGP SIGNATURE----- 

------_=_NextPart_001_01C1C38F.C7A84D40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Suggested work item for EAP WG Charter</TITLE>

<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=847411015-04032002>Pat,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=847411015-04032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=847411015-04032002>Your 
suggestion to work this&nbsp;within the context of DIAMETER has great merit. My 
only concern with it is that RADIUS vendors fully intend to support 802.1X and 
802.11, and 802.11 vendors fully intend to rely on this support. This means that 
either RADIUS would need to be upgraded to accommodate the needs of keying, or 
else the issue has to be brought out into the open so that people would know not 
to try to deploy products in this configuration, at least when their goal is 
security.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=847411015-04032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=847411015-04032002>-- 
Jesse</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Pat R. Calhoun 
  [mailto:[email-masked]]<BR><B>Sent:</B> Saturday, March 02, 2002 
  2:22 PM<BR><B>To:</B> [email-masked]'<BR><B>Subject:</B> [eap] RE: 
  Suggested work item for EAP WG Charter<BR><BR></DIV></FONT>
  <P><FONT size=2>&nbsp;</FONT> <BR><FONT size=2>-----BEGIN PGP SIGNED 
  MESSAGE-----</FONT> <BR><FONT size=2>Hash: SHA1</FONT> </P>
  <P><FONT size=2>&gt; The most critical issue still confronting IEEE 802.11 TGi 
  is how to</FONT> <BR><FONT size=2>&gt; accomplish&nbsp; dynamic key 
  distribution securely. TGi has done much</FONT> <BR><FONT size=2>&gt; good 
  work on how to effect key distribution between the 802.11</FONT> <BR><FONT 
  size=2>&gt; access point and station, but this architecture requires at 
  least</FONT> <BR><FONT size=2>&gt; one key distribution from an 802.1X 
  authentication server to the</FONT> <BR><FONT size=2>&gt; access point. Today 
  this is done using RADIUS, based on ad hoc </FONT><BR><FONT size=2>&gt; 
  techniques. These techniques cannot securely distribute a key for</FONT> 
  <BR><FONT size=2>&gt; its intended&nbsp; purpose. In particular, existing 
  RADIUS techniques</FONT> <BR><FONT size=2>&gt; may be suitable for 
  handing&nbsp; off a key between the authentication</FONT> <BR><FONT 
  size=2>&gt; server and the access point, intended for communication 
  between</FONT> <BR><FONT size=2>&gt; themselves alone, but as constituted 
  today they are insecure for</FONT> <BR><FONT size=2>&gt; transferring a 
  session key intended for use between the access</FONT> <BR><FONT size=2>&gt; 
  point&nbsp; and the station. To become secure the key handoff has to be</FONT> 
  <BR><FONT size=2>&gt; enhanced to&nbsp; incorporate additional cryptographic 
  state that can be</FONT> <BR><FONT size=2>&gt; used to provide assurances to 
  all three parties involved in the</FONT> <BR><FONT size=2>&gt; transaction. 
  Examples of such state are the information</FONT> <BR><FONT size=2>&gt; 
  communicated among the KDC and the communicating parties in the</FONT> 
  <BR><FONT size=2>&gt; Needham-Schroeder and Otway-Rees protocols.</FONT> </P>
  <P><FONT size=2>But the EAP WG is really not the right place to be working on 
  AAA</FONT> <BR><FONT size=2>protocols. In fact, I would urge you to take a 
  look at the Diameter</FONT> <BR><FONT size=2>protocol, currently being 
  standardized by the AAA WG. The NASREQ</FONT> <BR><FONT size=2>application 
  document already describes how such session keys can be</FONT> <BR><FONT 
  size=2>transferred to the access point in a secure fashion (using CMS as 
  the</FONT> <BR><FONT size=2>cryptographic protocol).</FONT> </P>
  <P><FONT size=2>&gt; As of now IEEE 802.11 TGi has no legitimate forum for 
  this</FONT> <BR><FONT size=2>&gt; discussion. IEEE 802.11 TGi cannot solve the 
  backend key handoff</FONT> <BR><FONT size=2>&gt; methodology itself, because 
  the communication among the backend</FONT> <BR><FONT size=2>&gt; components is 
  outside its scope. A second&nbsp; plausible venue--IEEE</FONT> <BR><FONT 
  size=2>&gt; 802.1 TGaa, chartered with fixing identified 802.1X 
  problems--also</FONT> <BR><FONT size=2>&gt; lacks the necessary charter to 
  tackle the backend. On the other</FONT> <BR><FONT size=2>&gt; hand, it is 
  infeasible for TGi to finish the design of the</FONT> <BR><FONT size=2>&gt; 
  handshake between the&nbsp; access point and the station without</FONT> 
  <BR><FONT size=2>&gt; relating this handshake to the backend key distribution, 
  which</FONT> <BR><FONT size=2>&gt; cannot be done until it is defined.</FONT> 
  </P>
  <P><FONT size=2>Right, and I would urge folks not to attempt to tackle this in 
  the</FONT> <BR><FONT size=2>IEEE SDO, since it is really a L3+ problem, and 
  work is already in</FONT> <BR><FONT size=2>progress... What we would really 
  like is for folks to comment on the</FONT> <BR><FONT size=2>draft which is 
  about to go through another WG last call.</FONT> </P>
  <P><FONT size=2>&gt; My fear is that if we do not find a venue for this work, 
  we will</FONT> <BR><FONT size=2>&gt; squander all the&nbsp; valuable work that 
  IEEE 802.11 TGi has done to</FONT> <BR><FONT size=2>&gt; rectify WEP's 
  deficiencies, and&nbsp; 802.11 security will remain no</FONT> <BR><FONT 
  size=2>&gt; better than the tarball the 1999 version of the&nbsp; 802.11 
  standard</FONT> <BR><FONT size=2>&gt; has bequeathed us. The EAP WG seems a 
  natural home for it. Please </FONT><BR><FONT size=2>&gt; consider including 
  this work in the EAP charter, and let me know if</FONT> <BR><FONT size=2>&gt; 
  there is&nbsp; anything I can do to help achieve this goal.</FONT> </P>
  <P><FONT size=2>I agree</FONT> </P>
  <P><FONT size=2>PatC</FONT> </P>
  <P><FONT size=2>-----BEGIN PGP SIGNATURE-----</FONT> <BR><FONT size=2>Version: 
  PGPfreeware 7.0.3 for non-commercial use &lt;<A href="http://www.pgp.com" 
  target=_blank>http://www.pgp.com</A>&gt;</FONT> </P>
  <P><FONT 
  size=2>iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk</FONT> 
  <BR><FONT size=2>KrLI6yBZv5W3diNoBGbfZ7rL</FONT> <BR><FONT size=2>=n34F</FONT> 
  <BR><FONT size=2>-----END PGP SIGNATURE-----</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1C38F.C7A84D40--

---

From: [email-masked] (Pat R. Calhoun)
Date: Mon, 4 Mar 2002 07:25:48 -0800

------_=_NextPart_001_01C1C390.DCA17400
Content-Type: text/plain

The point here is that there is only so much that can be done with
the RADIUS protocol, while still being able to call it RADIUS. If
changes to a protocol modify it's behavior completely (meaning more
than just adding new attributes), then the current deployment of
RADIUS servers is useless anyways, and an upgrade is required.
 
PatC

- -----Original Message-----
From: Walker, Jesse [mailto:[email-masked]] 
Sent: Monday, March 04, 2002 7:18 AM
To: Pat R. Calhoun; [email-masked]'
Subject: RE: [eap] RE: Suggested work item for EAP WG Charter

Pat,
 
Your suggestion to work this within the context of DIAMETER has great
merit. My only concern with it is that RADIUS vendors fully intend to
support 802.1X and 802.11, and 802.11 vendors fully intend to rely on
this support. This means that either RADIUS would need to be upgraded
to accommodate the needs of keying, or else the issue has to be
brought out into the open so that people would know not to try to
deploy products in this configuration, at least when their goal is
security.
 
- -- Jesse

- -----Original Message-----
From: Pat R. Calhoun [mailto:[email-masked]]
Sent: Saturday, March 02, 2002 2:22 PM
To: [email-masked]'
Subject: [eap] RE: Suggested work item for EAP WG Charter

- -----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 

I agree 

PatC 

- -----BEGIN PGP SIGNATURE----- 
Version: PGPfreeware 7.0.3 for non-commercial use
<http://www.pgp.com> 

iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk 
KrLI6yBZv5W3diNoBGbfZ7rL 
=n34F 
- -----END PGP SIGNATURE----- 

------_=_NextPart_001_01C1C390.DCA17400
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [eap] RE: Suggested work item for EAP WG Charter</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The point here is that there is only so much that can be done with</FONT>
<BR><FONT SIZE=2>the RADIUS protocol, while still being able to call it RADIUS. If</FONT>
<BR><FONT SIZE=2>changes to a protocol modify it's behavior completely (meaning more</FONT>
<BR><FONT SIZE=2>than just adding new attributes), then the current deployment of</FONT>
<BR><FONT SIZE=2>RADIUS servers is useless anyways, and an upgrade is required.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>PatC</FONT>
</P>

<P><FONT SIZE=2>- -----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Walker, Jesse [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>Sent: Monday, March 04, 2002 7:18 AM</FONT>
<BR><FONT SIZE=2>To: Pat R. Calhoun; [email-masked]'</FONT>
<BR><FONT SIZE=2>Subject: RE: [eap] RE: Suggested work item for EAP WG Charter</FONT>
</P>
<BR>

<P><FONT SIZE=2>Pat,</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>Your suggestion to work this within the context of DIAMETER has great</FONT>
<BR><FONT SIZE=2>merit. My only concern with it is that RADIUS vendors fully intend to</FONT>
<BR><FONT SIZE=2>support 802.1X and 802.11, and 802.11 vendors fully intend to rely on</FONT>
<BR><FONT SIZE=2>this support. This means that either RADIUS would need to be upgraded</FONT>
<BR><FONT SIZE=2>to accommodate the needs of keying, or else the issue has to be</FONT>
<BR><FONT SIZE=2>brought out into the open so that people would know not to try to</FONT>
<BR><FONT SIZE=2>deploy products in this configuration, at least when their goal is</FONT>
<BR><FONT SIZE=2>security.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>- -- Jesse</FONT>
</P>

<P><FONT SIZE=2>- -----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Pat R. Calhoun [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Saturday, March 02, 2002 2:22 PM</FONT>
<BR><FONT SIZE=2>To: [email-masked]'</FONT>
<BR><FONT SIZE=2>Subject: [eap] RE: Suggested work item for EAP WG Charter</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>- -----BEGIN PGP SIGNED MESSAGE----- </FONT>
<BR><FONT SIZE=2>Hash: SHA1 </FONT>
</P>

<P><FONT SIZE=2>&gt; The most critical issue still confronting IEEE 802.11 TGi is how to</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; accomplish&nbsp; dynamic key distribution securely. TGi has done much </FONT>
<BR><FONT SIZE=2>&gt; good work on how to effect key distribution between the 802.11 </FONT>
<BR><FONT SIZE=2>&gt; access point and station, but this architecture requires at least </FONT>
<BR><FONT SIZE=2>&gt; one key distribution from an 802.1X authentication server to the </FONT>
<BR><FONT SIZE=2>&gt; access point. Today this is done using RADIUS, based on ad hoc </FONT>
<BR><FONT SIZE=2>&gt; techniques. These techniques cannot securely distribute a key for </FONT>
<BR><FONT SIZE=2>&gt; its intended&nbsp; purpose. In particular, existing RADIUS techniques </FONT>
<BR><FONT SIZE=2>&gt; may be suitable for handing&nbsp; off a key between the authentication </FONT>
<BR><FONT SIZE=2>&gt; server and the access point, intended for communication between </FONT>
<BR><FONT SIZE=2>&gt; themselves alone, but as constituted today they are insecure for </FONT>
<BR><FONT SIZE=2>&gt; transferring a session key intended for use between the access </FONT>
<BR><FONT SIZE=2>&gt; point&nbsp; and the station. To become secure the key handoff has to be </FONT>
<BR><FONT SIZE=2>&gt; enhanced to&nbsp; incorporate additional cryptographic state that can be</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; used to provide assurances to all three parties involved in the </FONT>
<BR><FONT SIZE=2>&gt; transaction. Examples of such state are the information </FONT>
<BR><FONT SIZE=2>&gt; communicated among the KDC and the communicating parties in the </FONT>
<BR><FONT SIZE=2>&gt; Needham-Schroeder and Otway-Rees protocols. </FONT>
</P>

<P><FONT SIZE=2>But the EAP WG is really not the right place to be working on AAA </FONT>
<BR><FONT SIZE=2>protocols. In fact, I would urge you to take a look at the Diameter </FONT>
<BR><FONT SIZE=2>protocol, currently being standardized by the AAA WG. The NASREQ </FONT>
<BR><FONT SIZE=2>application document already describes how such session keys can be </FONT>
<BR><FONT SIZE=2>transferred to the access point in a secure fashion (using CMS as the</FONT>
<BR><FONT SIZE=2>cryptographic protocol). </FONT>
</P>

<P><FONT SIZE=2>&gt; As of now IEEE 802.11 TGi has no legitimate forum for this </FONT>
<BR><FONT SIZE=2>&gt; discussion. IEEE 802.11 TGi cannot solve the backend key handoff </FONT>
<BR><FONT SIZE=2>&gt; methodology itself, because the communication among the backend </FONT>
<BR><FONT SIZE=2>&gt; components is outside its scope. A second&nbsp; plausible venue--IEEE </FONT>
<BR><FONT SIZE=2>&gt; 802.1 TGaa, chartered with fixing identified 802.1X problems--also </FONT>
<BR><FONT SIZE=2>&gt; lacks the necessary charter to tackle the backend. On the other </FONT>
<BR><FONT SIZE=2>&gt; hand, it is infeasible for TGi to finish the design of the </FONT>
<BR><FONT SIZE=2>&gt; handshake between the&nbsp; access point and the station without </FONT>
<BR><FONT SIZE=2>&gt; relating this handshake to the backend key distribution, which </FONT>
<BR><FONT SIZE=2>&gt; cannot be done until it is defined. </FONT>
</P>

<P><FONT SIZE=2>Right, and I would urge folks not to attempt to tackle this in the </FONT>
<BR><FONT SIZE=2>IEEE SDO, since it is really a L3+ problem, and work is already in </FONT>
<BR><FONT SIZE=2>progress... What we would really like is for folks to comment on the </FONT>
<BR><FONT SIZE=2>draft which is about to go through another WG last call. </FONT>
</P>

<P><FONT SIZE=2>&gt; My fear is that if we do not find a venue for this work, we will </FONT>
<BR><FONT SIZE=2>&gt; squander all the&nbsp; valuable work that IEEE 802.11 TGi has done to </FONT>
<BR><FONT SIZE=2>&gt; rectify WEP's deficiencies, and&nbsp; 802.11 security will remain no </FONT>
<BR><FONT SIZE=2>&gt; better than the tarball the 1999 version of the&nbsp; 802.11 standard </FONT>
<BR><FONT SIZE=2>&gt; has bequeathed us. The EAP WG seems a natural home for it. Please </FONT>
<BR><FONT SIZE=2>&gt; consider including this work in the EAP charter, and let me know if</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; there is&nbsp; anything I can do to help achieve this goal. </FONT>
</P>

<P><FONT SIZE=2>I agree </FONT>
</P>

<P><FONT SIZE=2>PatC </FONT>
</P>

<P><FONT SIZE=2>- -----BEGIN PGP SIGNATURE----- </FONT>
<BR><FONT SIZE=2>Version: PGPfreeware 7.0.3 for non-commercial use</FONT>
<BR><FONT SIZE=2>&lt;<A HREF="http://www.pgp.com" TARGET="_blank">http://www.pgp.com</A>&gt; </FONT>
</P>

<P><FONT SIZE=2>iQA/AwUBPIFQkDN1fXKoxmisEQJjrACfWU6lDbDvnMJqWrkjehDs1sUFUz0AoIbk </FONT>
<BR><FONT SIZE=2>KrLI6yBZv5W3diNoBGbfZ7rL </FONT>
<BR><FONT SIZE=2>=n34F </FONT>
<BR><FONT SIZE=2>- -----END PGP SIGNATURE----- </FONT>
</P>
<BR>

<P><FONT SIZE=2>iQA/AwUBPIOR/DN1fXKoxmisEQIzEwCeJTz1HdajikwCyyZdmZRSP3AC5rkAnRq5</FONT>
<BR><FONT SIZE=2>R6tYe21/znRpMA4JcQ2tVFIY</FONT>
<BR><FONT SIZE=2>=Wx64</FONT>
<BR><FONT SIZE=2>-----END PGP SIGNATURE-----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1C390.DCA17400--