Subject: [eap] WG summary; action items

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Aug 2003 12:48:13 +0300

Hello folks,

This is a summary of the meeting in Vienna, including major
decisions (detailed issues discussions are in the minutes),
and action items. If you are on the "To:" field of this e-mail,
you have a marked action item. If so, check what it is, and
let us know if you think the marked completion dates are
achievable.

Other comments on the summary are welcome as well,
particularly if we have missed something that needs
to get done.

DECISIONS

   D1) State machine document (draft-vollbrecht-eap-state-04.txt)
       will become a WG document in its next revision.

   D2) Two issues identified in RFC 2869bis
       (draft-aboba-radius-rfc2869bis-22.txt) after
       its IESG approval will be discussed on the list
       and resolved.

ACTION ITEMS

   A1) Close open 2284bis issues, post new draft (Henrik L,
       Aug 30th -- Ongoing)

   A2) Third and final WG last call on 2284bis (chairs,
       Aug 30th)

   A3) Submit version 07 of the keying framework draft
       (Bernard A, Aug 10 -- Done)

   A4) Progress discussion on keying framework and Russ'
       requirements (Bernard A, Russ H, Aug 30 -- Ongoing)

   A5) Find reviewers for keying framework (chairs, Aug 30 --
       Ongoing).

   A6) Produce a new version of the state machine without
       overspecifying the AAA parts (Pasi E, Nick P, John V,
       Aug 20)

   A7) Discuss and work off-line to determine what 3GPP requirements
       for network selection are and where they fits in IETF protocols
       (Jari A, Farid A, Aug 20 -- Ongoing)

   A8) Propose additional security property claims
       for 2284bis which can be used to describe method
       security more accurately than is possible today
       (Uri B, Aug 20)

   A9) Ensure that IKEv2 EAP MitM attack with non-kg method
       issue is registed in IPsec WGs issue tracker (Jari A,
       Aug 5 -- Done)

   A10) Ensure that IKEv2 binding solution agrees with the
        binding draft proposals (Bernard A, Aug 20 -- Ongoing)

   A11) Try to initiate interest to review and complete
        the compound authentication draft by talking to
        several WG members and outside experts (chairs,
        Aug 20 -- Ongoing)

   A12) Architectural discussion of the usage of EAP in
        DHCP and other applications (chairs, ADs?)

CHARTER REVIEW

In terms of charter modifications, we only need some minor touch ups at
this time, and adjustment of milestones.  RFC 2284bis has completed its
second EAP WG last call, and is currently in the process of resolving
last call comments.

Goals and Milestones:
Sep 03    RFC 2284bis submitted for publication as a Proposed Standard
Dec 03    EAP Keying Framework document submitted for publication as an
           Informational RFC
Dec 03    EAP State Machine document submitted for publication as an
           Informational RFC
Dec 03    EAP compound binding document submitted for publication as an
           Informational RFC.

Note that there are currently a number of documents related to EAP
but which are not within the charter. However, it has earlier been
agreed that the base EAP documents will be completed before methods
work can be chartered (and some of methods work might be Informational
even then).

TEXTUAL SUMMARY

The EAP working group is close to finishing the revised EAP base
specification (2284bis). Three issues remain which can be classified
as small, and one additional issue can perhaps be treated as new
work. We will issue one final WG last call on the document once
these issue have been resolved.

Related to the work of EAP WG, the RADIUS EAP specification (2869bis)
has been approved by the IESG. Since then, however, two inconsistencies
have been detected between IEEE and IETF specifications, and these are
intended to be corrected in AUTH48. They are also discussed in the
IEEE 802 plenary this week. Similar to 2869bis, a new version
of the DIAMETER EAP specification has been produced in the AAA working
group. This is a rather exact copy of 2869bis, but adds a proxy-free
operation mode and key transport AVPs.

Significant progress has been made in EAP WG with respect to two
individual drafts, the EAP state machine and EAP keying framework.
The intention is to take adopt these as WG items now that work on
2284bis is slowing down. However, these drafts are not complete yet
and have some risks associated with them:

1. The keying draft now addresses Russ' requirements for
    keying -- but there are two or three requirements which
    we have not fulfilled yet and which can also be troublesome
    on IEEE link layers. The hardest problems appear to be
    authorization of AAA nodes, and the naming of "phase 1"
    and "phase 2" security assoications. The latter issue
    may require changes to the current IEEE 802.11i protocol
    proposals.

2. The state machine model has ventured too far into the
    domain of AAA in its attempt to represent EAP passthrough
    nodes. This has also impacted IEEE, which has replaced
    its fully-fledged AAA layer with an EAP-only AAA layer.
    This needs to be corrected. (Otherwise the state
    machine is relatively stable.)

The state machine will become a WG item in its next
version. The intention is also for the keying framework
to do the same, but for this we will wait with the
question to the WG until 07 is posted to the directories.

Farid Adrangi presented a request from 3GPP to provide
for network selection functionality in EAP. After discussion
it was not clear that there was an agreement on whether this
functionality should be a part of EAP. Off-line discussion
with the involved folks needs to be initiated in order to
ensure that 3GPP is sent to the right direction, and that
their requirements get fulfilled. Currently, it is unclear
what that right direction is.

Uri Blumental presented a security analysis of EAP SIM,
the GSM version of SIM card authentication in EAP. There
are two issues relating to the claim of 128 bit security
which reduces to 64 bits due to problems, and one issue
about independence of individual authentications in EAP
SIM. Draft authors have adopted proposed solutions to the
64 bit security problem. However, the session independence
property can not be achieved using GSM authentication, while
its available in some other methods (e.g. UMTS authentication
or EAP TLS). From the point of the EAP WG, a minimal
requirement is that the security properties of methods are
described correctly and accurately. This may require some
improvements in the current 2284bis requirements for
methods to describe their security properties.

Jose Puthenkulam's work on compound authentication
man-in-the-middle attacks has progressed by adopting
comments from the list, and a new draft revision
exists. Several IETF protocols, including IKEv2 are
employing techniques to prevent these attacks, and
further work on EAP tunneling proposals is also
waiting the results of this work. From the point of
view of producing secure protocols, it is essential
to complete this work item before, for instance,
IKEv2 appears as an RFC. The authors of the draft are
willing to complete it, earlier reviewers have to
first verify that their comments have been properly
addressed.

Related to the above attacks, the chairs have suggested
on the IPsec mailing list that IKEv2 be changed to
allow only key-generating methods. This would make it
possible to prevent man-in-the-middle attacks while
still using key-generating versions of the existing
methods. The used RADIUS servers would have to be updated,
but existing credentials could be kept. Discussion on
this is still going on.

Several folks proposed the use of EAP in non-access and
non-IKEv2 context. These proposals ranged from the use
of EAP to bootstrap DHCP security to general-purpose
application-specific key generation. This is an architectural
issue where the IETF needs to take a standpoint of what
is the right direction for this work. The use of EAP and
different EAP methods to secure access is normally
acceptable, given the different kinds of access networks,
deployment of widely different access credentials (passwords,
token cards, SIM cards etc). However, the use of EAP in a
wide variety of application level protocols may not be desireable,
given its inefficiency when running large amounts of data
(such as certificate chains) over IP, and the potential
for interoperability problems. Perhaps it would be better
to provide a limited set of authentication methods at
the application layer, and allow bootstrapping of those
methods from EAP where necessary. However, this would require
continuing with PIC, whereas currently most people's energy
appears to be concentrated on making IKEv2 work with EAP.

Also, a number of new methods (EAP Archie, EAP LDAP, EAP
IKEv2, PEAPv2, EAP smartcard) were presented.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap