Minutes of the 5/9/03 IETF/IEEE 802.11 Conference call

[Bernard Aboba <aboba@internaut.com>]

Attendees: Dave Halasz, Dorothy Stanley (IEEE), Thomas Narten, Erik
Nordmark, Russ Housley (IESG), Bernard Aboba, Jari Arkko, David Mitton

Agenda

IEEE 802.11 Liason letter:
http://www.drizzle.com/~aboba/IETF56/EAP/11-03-243r2-I-Input-to-IETF-EAP-WG-March-2003.doc

Potential IETF response to 802.11 Liason letter:
http://www.drizzle.com/~aboba/IETF56/EAP/ietf56-eap.pdf

IEEE 802.11 Liason Report:
http://www.drizzle.com/~aboba/IETF56/EAP/11-03-264r0-W-IETF_Liaison_Report_March_2003.ppt

IPR Issues:
http://www.drizzle.com/~aboba/IETF56/EAP/alcatel-letter.pdf

Minutes

The meeting started off with Dorothy presenting the IEEE 802.11 liason
letter presented at IETF 56 in San Francisco. This letter requests
development of EAP methods meeting IEEE 802.11 requirements, as well as
noting that EAP MD5 (the currently mandatory to implement EAP method) does
not meet them.

The IETF requires a mandatory to implement authentication method for
purposes of interoperability. Bernard noted that there is no explicit
requirement that the method actually be appropriate, but that seems to
be obvious. Russ noted that in several cases, the mandatory to implement
method has not been appropriate.

In RFC 2284bis there was a question of what entities had to implement the
mandatory to implement method. The WG concluded that an EAP authenticator
supporting only pass-through operation with an authentication server did
not have to implement the mandatory method. That implies that an EAP
implementation incapable of peer-to-peer operation is compliant. Russ
indicated some surprise at this decision, and agreed to think over
whether this makes sense and whether it is compliant with the spirit
of IETF "mandatory to implement" requirements.

We then went on discuss how the IETF would respond to the IEEE 802.11
liason letter. Dan Romascanu has been appointed the IEEE
802 liason from IETF, but it was not clear whether this was only for
IEEE 802.1 or encompassed IEEE 802.11 as well. Thomas Narten noted that
having an official IEEE 802 liason for IETF was a prerequisite for getting
a response together.

At IETF 56, Erik Nordmark presented his views on how the IETF might
respond to the IEEE 802.11 liason letter. This did not represent the
official views of the IESG which has not discussed a response. But Erik's
slides did receive a favorable response from the EAP WG. Thomas noted that
it was expected that the IEEE 802 liason would lead the process of
organizing a response. Thomas was unclear about how the liason was chosen
-- whether this would be done by IAB or IESG or some combination of both.

Erik's recommendation is for IETF to decline IEEE 802.11's request to
change the mandatory to implement method in RFC 2284bis, but perhaps to
consider changing this later. Since other SDOs (such as 3GPP) have
expressed interest in developing methods for their own use, it is not
clear that a single mandatory to implement method can satisfy all needs.
For example, 3GPP might prefer EAP-SIM or AKA as their mandatory method,
while IEEE 802.11 might want something else. So it is somewhat more
flexible for each SDO to have its own requirements.

The issue that arises in changing the mandatory to implement method in
RFC 2284bis is that this would introduce a substantial delay while the
appropriate method was developed and selected. Jari Arkko noted that
such a delay would be counter-productive since the security enhancements
and clarifications of RFC 2284bis would be less likely to be deployed
if the specification is delayed. His recommendation was that the choice
of a new mandatory to implement method be handled later, so that
RFC 2284bis could proceed. For example, this could occur after the
EAP WG charter is modified to allow methods to be considered.

Erik's also recommended that IEEE 802.11 requirements and goals be
captured in an Internet Draft. These requirements are not evaluation
criteria. Once these criteria were published, then methods
could be verified as conformant with the base documents (RFC 2284bis and
Key Framework) as well as the IEEE 802.11 requirements. EAP methods could
be published as Informational RFCs, and work could start before RFC
2284bis and the Key Framework documents go to RFCs.

Erik also recommended development of a Best Current Practice (BCP)
document describing the requirements for EAP usage in various
circumstances. Bernard noted that this discussion was being
incorporated into the RFC 2284bis security considerations section, but
would not recommend specific methods, just describe the requirements.

Discussion then moved on to IEEE 802.11's response to previous IETF
requests. These included a request that IEEE 802 documents relating to AAA
be published as Internet-Drafts and reviewed in IETF. In IEEE 802.1, this
has been the past practice with SNMP MIBs and AAA documents such as
draft-congdon-radius-8021x. However, that process was not followed in IEEE
802.11f.

Dorothy noted that she has been encouraging IEEE 802.11 to move toward
adopting IEEE 802.1 practices with respect to IETF review and publication
of AAA documents. She then suggested that IETF comments on IEEE 802.11f
RADIUS usage be handled via the interpretation process.

Thomas asked what the interpretation process was used for. It is typically
used for clarifications of the specification, but also can be used to
point out errors. This process can then lead to a revision PAR where the
specification is revised. However, Dorothy noted that IEEE 802.11f was
very far along in the IEEE 802.11 standards process, so it could not be
changed at this time.

It was noted that the IEEE 802.11f RADIUS usage specification was likely
to require clarification, once implementation began. Dorothy noted that it
only takes one or two implementations to bring up issues and cause some
customers to include IAPP on a checklist.  So it is better to fix things
early rather than having to deal with them once there are implementations
in the field.

Bernard noted that IEEE 802.11f RADIUS usage includes use of the attribute
hiding algorithm originally introduced in RFC 2865. This algorithm uses
MD5 as a stream cipher, and so results in key stream compromise whenever
the Request Authenticator repeats. Although the RA is 128 bits in
practice, NAS devices often have low entropy and so repetition can occur.
In RADIUS it is possible to launch a known plaintext attack by
attempting a logon via PAP and then capturing the hidden User-Password
attribute issuing from the RADIUS client (NAS) on the other side, in order
to collect key streams corresponding to a given Request Authenticator. When
the RA repeats, on this or any other NAS using the same shared secret,
anything hidden with the keystream (such as keys) is compromised. As a
result, RFC 2869bis includes advice against handling PAP authentication on
the same RADIUS proxy or server on which IEEE 802.11 access is handled.
Also, the RADIUS shared secret needs to be unique for each
NAS-proxy/server pair.

Since IEEE 802.11f uses the User-Password attribute and the same hiding
algorithm as RFC 2865, there is a question about whether it opens up a
vulnerability in RADIUS. This issue is being considered in RFC 2869bis.
It was also noted that IEEE 802.11f uses IPsec manual SAs, so that there
are issues with respect to replay protection and rekey. This can come up
if IEEE 802.11f is used to tunnel packets between APs in the future.

Russ also noted that in his requirements presented at IETF 56, it is
necessary for compromise of one NAS not to result in compromise of another
NAS. This appears to be violated if IEEE 802.11f is used to transport a
PMK from one NAS to another. Bernard noted that he interpreted the
requirement as saying that the keys for different NASes needed to be on
different branches of the key hierarchy. Russ agreed, but noted that this
was a necessary but not sufficient requirement for Perfect Forward Secrecy
(PFS). Within the EAP key hierarchy, "branch separation" between PMKs is
only possible if the keys are derived from the Extended Master Session Key
(EMSK), since the EMSK is never transported to any NAS. As a result, it is
not possible for an IAPP-based key transport scheme to achieve branch
separation.

The question was raised about how IETF SEAMOBY WG was going to handle the
issues encountered in IEEE 802.11f. Bernard noted that there were two
problems: one is how to obtain the IP address of a NAS/AP based on its MAC
address; another is how to secure communications between NAS/APs. It
does not appear that SEAMOBY WG has yet tackled these problems.

It was asked whether manual configuration of IPsec keys was deployable.
Bernard indicated that this was difficult since there are N(N-1) possible
security associations -- and thus a KDC model is attractive.

Dorothy also mentioned that IEEE 802.11 was interested in
the work of the SEAMOBY WG (such as light weight access point protocols)
as well as in IETF work on fast handoff.  However, the level of interest
in these subjects had not yet gotten to the level of a formal request.

Dorothy noted that several vendors were now producing 802.11 switches to
which access points are attached. This model potentially improves the
manageability and scalability of 802.11 deployments, but the protocols
used between the switch and access points are not standardized. Thomas
noted that light weight access point protocol was not a work item of the
SEAMOBY WG, but rather an individual submission
(draft-calhoun-seamoby-lwapp-01.txt).

On the subject of 802.11 fast handoff, there is currently no IETF work.
However, Bill Arbaugh of the University of Maryland is going to be
proposing formation of an IRTF WG to look at security and performance
issues of alternative approaches, including IAPP and AAA-based approaches.
A question arose as to the division of labor between such an IRTF WG if it
is formed and the newly formed IEEE 802 Handoff Study Group, lead by
David Johnston (see http://www.ieee802.org/handoff/). Dave Halasz said
that the study group would first meet at the Dallas IEEE meeting, and it
wasn't clear to him what the focus would be. Much of the discussion at the
previous call for interest had centered around IETF work.

The last item on the agenda was an IPR disclosure made by Alcatel in IEEE
802.1. It appeared that this disclosure applies to IEEE 802.11 as well as
EAP WG. Bernard noted that the IETF Secretariat had sent a letter to
Alcatel requesting a disclosure relating to the patent discussed in the
IEEE document, and that a response had been received. Thomas noted that
the response should be posted on the IETF IPR web page.