Minutes of the 8/22/03 IETF/IEEE 802.11 Liason Call

[Bernard Aboba <aboba@internaut.com>]

Minutes of the 8/22/03 IETF/IEEE 802.11 Liason Conference Call

Attendees: Dorothy Stanley, Russ Housley, Margaret Wasserman, Thomas
Narten, Bernard Aboba, Jari Arkko, David Mitton

Scribe: Bernard Aboba

IEEE 802.11i status, timeframe and dependencies (Dorothy Stanley)

Dorothy started off by summarizing IEEE 802.11i status.
She noted that IEEE 802.11i was currently in recirculation ballot,
which is roughly equivalent to IETF WG last call.  At least one
more recirculation ballot was likely.  This translates into approval
as a final standard some time in the spring, and a need to resolve
all dependencies by late 2003.

In terms of dependencies, IEEE 802.11i depends on IEEE 802.1aa, as
well as the IETF CCMP draft (now in the RFC Editor Queue).  Dorothy
noted that IEEE 802.11i needs an RFC # assigned to this document
so that the reference can be resolved.  To move forward, a request
needs to be sent to the IESG <iesg@ietf.org> and CC'd to the RFC-Editor
<rfc-editor@rfc-editor.org>.

IEEE 802.1aa depends on RFC 2284bis (in EAP WG last call), RFC 3579
(RADIUS/EAP, assigned an RFC # but not published yet),
RFC 3580 (802.1X Usage Appendix, assigned an RFC # but not published
yet).  RFC 3579 depends on RFC 3576 (Dynamic Authorization, published),
which in turn depends on RFC 3575 (RADIUS IANA considerations, published).

IETF document status (Bernard Aboba, David Mitton, Jari Arkko)

Currently RFC 2284bis is in its second WG last call.  22 issues have been
raised, and all but two are resolved.  The schedule is to resolve all the
remaining issues and for Henrik Lefkowetz to put out an -05 version by the
end of August.  Then another (and hopefully last) WG last call will ensue.

Overall, it seems reasonable that RFC 2284bis will be sent to the IESG by
late 2003.  This should result in an RFC # being available in time
to avoid delaying IEEE 802.11i.

The EAP Key Framework Document and EAP State Machine documents are both
about to become EAP WG work items.

The Diameter EAP document has made rapid progress since IETF 56, and is
now being edited by Pasi Eronen, who has also been editing the EAP
State Machine document.  This document largely parallels RFC 3579
(RADIUS/EAP) with the exception of the EAP Grouped Key AVP.  It appears
that some of the attributes included in this Grouped AVP are unnecessary
and potentially harmful. For example, the ciphersuite is not needed
because the EAP Keying material is ciphersuite independent; the key type
is not needed because the type is always a master session key, and never
a transient session key.  The remaining major issue left is key naming.
Is a key name to be included with the key, or is it implicit somehow?

Outstanding IEEE 802.11 liason requests (Dorothy Stanley)

Dorothy then went over the outstanding liason letters, and IEEE 802.11's
read on IETF responsiveness to those letters.  Dorothy noted that there
are two letters that have been sent, one in February 2002, and another
in March 2003.  There was a third letter that had been drafted but has
not been sent, and Dorothy noted that work was not ongoing on this, so
that there are no pending additional liason letters.

The February 2002 letter requested a forum for discussion of EAP methods,
and subsequently, the IETF formed the EAP WG.  Thomas noted that the EAP
WG was not chartered to work on EAP methods, but it was noted that EAP
methods are being presented to the WG.  Bernard noted that this was for
the purpose of validating RFC 2284bis -- can the methods work with the
revised EAP spec, or are there problems?

In the original letter, IEEE 802.11 also requested work on EAP Key
Management.  The EAP WG is now preparing to accept the EAP Key Framework
draft as a WG work item.  Jari noted that a design team was going to
be formed to make more rapid progress on the keying framework, now that
work on RFC 2284bis was winding down.

The original letter also requested work on keying attributes.  This work
is ongoing with the AAA WG, as part of the Diameter EAP specification.

Discussion then turned to the second liason letter.  This letter requested
work on methods meeting the IEEE 802.11i requirements, as well as
potential changes to the mandatory-to-implement method in RFC 2284, which
is EAP-MD5-Challenge.  Dorothy pointed out that RFC 2284 effectively
requires implementation of a method that is insecure when used with IEEE
802.11i.

Bernard noted that in RFC 2284bis there was a discussion of where the
mandatory method needs to be implemented.  It needs to be implemented
on the Supplicant as well as the authentication server, but only on an
authenticator if it can terminate authentication itself (e.g. not
pass-through).

Margaret noted that having to add in code that was not only useless
but insecure was not a good thing -- particularly in embedded systems
where the code could consume power and memory unnecessarily.  Bernard
took an action item to raise this as an issue in RFC 2284bis.  Perhaps
the right thing to do is to say that EAP MD5-Challenge is not mandatory
to implement in situations where mutual authentication is required.

In terms of the IETF response to the letter, Erik Nordmark provided
a recommendation at IETF 56.  The recommendation was to turn the
IEEE 802.11i requirements into an IETF Draft and publish it as an RFC.
Bernard noted that in the discussion of EAP SIM some potential new
requirements had arisen -- the notion of "session independence."

In RFC 2284bis there are "security claims" defined which include things
like key strength.  The review of EAP SIM presented by Uri Blumenthal
at IETF 56 showed how EAP SIM would only have 64 bits effective key
strength in some circumstances.  The authors of the draft have addressed
these comments so as to restore 128 bits effective key strength.  However,
another issue is "session-independence."

Russ asked whether lack of "session independence" meant that if one NAS
was compromised then keys for other NASes were also compromised.  Jari
clarified that this was not the meaning.  Rather, it refers to the
consequences of compromising Kc, which is an intermediate work product.
Note that this is not the same as Ki, the long-term secret.  If Kc is
compromised, then it would be possible to masquerade as the authenticator
from that point forward.  So the question was raised as to whether the
IEEE 802.11i requirements should list "session independence" as a
requirement or not.

Overall, the envisaged process is that the IEEE 802.11i requirements
will be published and will reference security properties defined in
RFC 2284bis.  Subsequent EAP method specifications will include
security claims based on those definitions, and potentially a statement
about whether the IEEE 802.11i requirements are met.

Margaret asked whether IEEE 802.11i could define its own
mandatory-to-implement method.  Dorothy said that 9 months had been spent
trying to do this, but ultimately it is the IETF that needs to define EAP
methods.

Jari noted that once EAP methods are defined and published, it might
be possible to go back and select a new mandatory-to-implement method.
But before we have methods defined, choosing one is not possible.

A question arose as to when the EAP WG work would look at methods.
The answer is that when the EAP Key Framework and RFC 2284bis are
complete, this could be considered.  However, it was noted that even
then the IETF does not want to charter an open ended WG to look at
any methods which are submitted to it.

Russ noted that the IETF only does its own cryptographic work if
there is no alternative.  In general, the IETF looks to NIST or
other recognized bodies with cryptographic expertise.  Ocassionally
there are situations (such as have occurred in S/MIME) where NIST
is not willing to sign up to do some critical work, and the IETF
needs to take that on.  But this is a rare event.

Based on this,  EAP methods looking to avoid the "slow path" should
rely on algorithms with well understood cryptographic properties.
These would be algorithms already documented in RFCs, standards
from other SDOs, the NIST "modes" document, cryptographic literature, etc.
Since it is possible to introduce vulnerabilities into EAP methods
even if they are based on well-established algorithms, if possible it
is best to rely on established cryptography rather than "rolling your
own."

IETF responsiveness to IEEE 802 requests (Dorothy Stanley)

Based on the discussion of the liason letters and the IETF responses
to them, the question was asked "Is IEEE 802.11 satisfied with
IETF progress on the requests?"

Dorothy's answer was that she considered the IETF to be responsive.

At the IEEE 802.11 plenary in San Francisco, Dan Harkins had noted
that the IETF had been remiss because "the EAP WG should have addressed
the key naming issue 6 months ago."

>From the IETF perspective, this comment is somewhat puzzling, since
there is no outstanding liason request from IEEE 802 relating to
key naming. For example, Liason letter #1 does not mention key naming,
as this was not on the radar screen at the time.

Nevertheless, the EAP WG will be addressing the key naming issue
within the EAP Key Framework document.  Key Naming was included
as a requirement by Russ Housley in his presentation to the
AAA WG at IETF 56.

However, this raises the question about how the work of the two
organizations is to be coordinated.  If both IETF EAP WG and
IEEE 802.11i are working on key naming, what process do we use
to ensure that both organizations come up with the same answer?

For example, it was noted that Jesse Walker's suggestions on key
naming were accepted in EAP WG and are now incorporated into the
EAP Key Framework document version -07.  These suggestions are
based on the EAP key hierarchy, as the names of children are
based on the names of parents plus additional material.

However, Jesse's suggestion was not adopted in IEEE 802.11i,
which adopted a different PMK naming scheme based on the key
itself.  Russ Housley noted that he had reviewed this scheme
and had problems with it -- it inherently did not specify the
location of the PMK within the hierarchy, since the PMK name
was not based on the name of its parent, but was independent
of it.

Bernard noted that the PMK could be derived in different ways,
and the lack of "rooting" in the hierarchy implied by the
IEEE 802.11i naming scheme implies that the algorithm by which
the PMK is derived is not determinate.  This could conceivably
result in situations where one or both peers could have to do
an exhaustive search of key hierarchies derived from multiple
algorithm sets.  This could be a large tree -- and was troubling
given that the problem being solved is "fast handoff".

Jari noted that an EAP Key Framework design team would be formed
to make more rapid progress. Candidates for the team include
Bob Moskowitz, Jesse Walker, Tero Kivenen, Pasi Eronen, Bernard
Aboba and Jari Arkko.  One or more of Bill Arbaugh's students
might also be available.

Dorothy suggested a plan for getting to closure, which was to
attempt to reconcile the two points of view at the IEEE 802.11i
interim in Portland, then do further work in the EAP Key
Framework Design Team and IEEE 802.11i.  Finally, the EAP WG
and IEEE 802.11i could hold a joint meeting on October 15, 2003
at the IEEE 802.11i interim in Herndon, Virginia to resolve
remaining issues.

Bernard and Jari agreed to announce the October 15, 2003 date to
the EAP WG and gauge reaction (which has been positive so far).

Potential RADIUS work in the IETF (Bernard Aboba & Randy Bush)

A RADIUSEXT mailing list has been started on ops.ietf.org to discuss
future RADIUS work within the IETF.  So far, work items under
discussion relate to RADIUS prepaid support; standardization
of WLAN attributes; a RADIUS UDP transport profile; and
attribute space extension.

The goal of the RADIUS UDP Transport work item is to specify
congestion control and jittering for RADIUS -- failover is
considered out of scope. RADIUS does not have the equivalent
of a Diameter "heartbeat" -- a non-forwardable message that
indicates whether the next hop is alive.  As a result, a
new command would need to be added to RADIUS to be able to
do RFC 3539-style failover and this is considered out of
bounds.

A number of WLAN attributes have been specified in WFA,
as well as by vendors and IEEE 802.11. There is also some
discussion of additional IEEE 802.1 attributes.

The need for attribute extension is not very well delineated
at the moment, so it is not clear that this will go forward.

There has also been a suggestion that the WG handle Bill Arbaugh's
RADIUS Handoff extension draft.  However Bill has requested that this work
not become an IETF WG work item until his group has implemented it and
verified that it is useful.  At that point, the draft could conceivably be
published as an Experimental RFC.  Experimental RFCs can be upgraded to
Standards Track at some point.

Fast(er) Handoff (All)

IEEE and IETF plans in the Fast Handoff area were discussed.

Currently IEEE 802.11i contains some minimal fast handoff
functionality (PMK caching, pre-authentication and PMK
naming).  It was noted that there is no work needed in
RFC 2284bis to enable pre-authentication.  Some work
is ongoing in the EAP Key Framework document relating to
PMK naming. Since EAP WG and IEEE 802.11i are working on
some of the same issues there is a need for coordination
between the two.

A study group on Fast Handoff is also likely to be
formed in September 2003. There is an IRTF WG being
suggested by Bill Arbaugh, focussing on IETF aspects
of fast handoff, such as AAA and potentially work on
"triggers".  These two groups probably also need to
coordinate to some extent.

There is a Handoff Executive Committee Study Group (ECSG).
This focusses on the relationship between
L2 and L3.  On the IETF side, the DNA BOF at IETF 57 dealt
with some of the same issues -- ambiguous layer 2 "hints".  For
example, the SSID "default" doesn't tell you whether you've
attached to the same network or a different network, so some
more definitive hints might be helpful in optimizing IP
address assignment in both IPv4 and IPv6.  For example, if
a host new that it was attached to the same network and that
it had a valid IP address on that network, it would only need
to test reachability to the default gateway.  If that was
successful, the address could be used with no need for DAD
(not even optimistic DAD).

However, if the host knew definitively that it had changed
subnets and had no valid IP address on that subnet, then it
could immediately begin IP address acquisition.

In the DNA Charter under discussion, liason with Handoff
ECSG is discussed, and this appears to make sense.

PANA

Last on the agenda was a discussion of PANA.

Bernard noted that at IETF 47, there had been an EAP BOF, and
Jeff Schiller had given a sermon in which he indicated that
use of EAP over the Internet without a protected channel
underneath was a bad idea.  This is because EAP does not have
a protected algorithm negotiation, and is an ACK/NAK protocol.
Therefore an authentication algorithm running over EAP will
be inherently less efficient than one running over TCP, and
this can result in very long authentications.  For example,
PEAP can require 20 roundtrips or longer if sufficiently
large certificate chains are used.  This problem does not
occur when running over TCP since a window larger than 1
can be used and so an entire cert chain can be sent in a
single round-trip if the window is large enough.

It is also possible to use IP fragmentation instead of
EAP fragmentation by passing a large MTU to EAP.  However,
Thomas noted that IP fragmentation only works if the
sender has an assigned IP address.  If 0.0.0.0 is used
as the source (as it is in PANA), then datagrams can
be reassembled incorrectly.

Margaret noted that it was important to raise these issues
with PANA early on, rather than let them continue work,
letting the issues surface late in the process.  It was
resolved to bring up these issues to the PANA WG.