eap Mailing List: minutes from IETF-61

[Jari Arkko (jari.arkko]

Here are the preliminary minutes from our meeting
in Washington DC. If you spot something additional
that should be included, let the chairs
know.

Thank you Gerardo for taking notes!

--Jari

Extensible Authentication Protocol WG (eap)

IETF-61 Minutes, Wednesday, November 10, 2004 at 0900-1130
==========================================================

CHAIRS: Bernard Aboba <aboba [at] internaut.com>
        Jari Arkko <Jari.Arkko [at] ericsson.com>

SCRIBE: Gerardo Giaretta <Gerardo.Giaretta [at] TILAB.COM>



1. PRELIMINARIES, CHAIRS
------------------------

Presentations on the web: http://www.drizzle.com/~aboba/EAP/IETF61

Issues on the web: http://www.drizzle.com/~aboba/EAP/eapissues.html

- Agenda Bashing

- Documents Status

RFC 3579 "EAP over RADIUS" published earlier
RFC 3748 "2284bis" published earlier

EAP state machine in RFC editor queue. Some comments -> back to the
WGLC and then back to RFC editor.

[Bernard]: We need a review and approve from others than authors

[Hannes]: I'm not author and I approve. We implemented this state machine.

[Bernard]: Did you find issues?

[Hannes]: I'll let you know

EAP Keying framework: discussion today

EAP over Diameter (AAA WG - draft-ietf-aaa-eap-09.txt) approved by
IESG

Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt):
waiting input from IEEE WIEN next week

Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt):
to be sent to IESG

NAI Update "RFC2486bis" [RADEXT WG]: when I-D submission re-opens will
be submitted and sent to the IESG

Methods documents
3 submitted for RFC publication (EAP-SIM, EAP-AKA, EAP-PSK)
Many issues in EAP-SIM reviewed by Bernard

Binding Problem definition: not updated since IETF-58 (abandoned)

Other work: need review from the WG
EAP usage in PANA
EAP usage in MIP6
EAP usage in DHC

[Hannes]: EAP in NSIS because of authorization issues. In NSIS WG we
have a number of docs describing authentication and authorization
issues and need comments

[Bernard]: ISMS too

[Glenn]: I have two questions about the directions of the WG. There is
work that has nothing to do with authentication (netdisc). Moreover no
standardization of EAP methods.  1) EAP for authorization and other
usages. I think we should develop a flexible authentication and
authorization protocol and include network selection and
discovery. What do you think about this? Or would you continue to add
stuff to EAP?

[Bernard]: the scope of EAP is clear. Applicability statement and IANA
considerations state the purposes of EAP

[Glenn]: Which are the future policies?

[Bernard]: to be described in future documents. Can you send an email
question?

[Glenn]: OK 2) Regarding EAP methods. People need guides from the
IETF: IEEE for example. They did not standardize EAP methods. The 3
EAP methods mentioned in slides are about 3GPP

[Jari]: Not for PSK

[Glenn]: Are we going to standardize methods?

[Bernard]: We have one method we need in standard track

[Jari]: People can develop new methods and standard tracks. If there
is interest in people and vendors we will standardize.

[Glenn]: It's very difficult to publish standard as individual submission

[Bernard]: We already developed the process for publication of EAP methods

[Dorothy]: To clarify 802.11 prospective: 802.11 made the decision not
to select an EAP method. There are only requirements for EAP methods
in IEEE.





2. KEYING FRAMEWORK DISCUSSION, BERNARD ABOBA
---------------------------------------------

See issue list page at http://www.drizzle.com/~aboba/EAP/eapissues.html

Requirements from Rouss Housley
Keying framework try to analyze the security of EAP system
The requirements are a sort of charter for the document

[Glenn]: I don't remember any WG consensus on Rouss requirements

[Bernard]: We took these requirements as a challenge. So far we did
not find any problems with these requirements.

[Jari]: I agree with Glenn. We  don't need to agree with Rouss' requirements if we think he is wrong

[Glenn]: These requirements seem to drive many EAP method design and I
think this is a problem. Could we have a WG document regarding these
method-design principles?

[Bernard]: EAP keying should do this

[Glenn]: I don't think it is acceptable to base these principles on a presentation

[Jari]: Let's discuss technical issues

[Hannes]: One requirements states that an acceptable solution must
authenticate all parties. We are not always authenticating all parties

[Bernard]: the important thing is to be clear on limitations and state them

21 issues (7 editorial and 14 technical)
Discussion on most important open issues:



ISSUE 254: KEY LIFETIMES
EAP does not negotiate the lifetime of exported keys
EAP does not support re-key of exported keys without re-authentication
Secure Association protocol may support re-key without re-authentication
EAP itself is not managing the lifetimes but SA protocol is responsible for 
lifetimes

[Jari]: Just a clarification: re-key does not extend the original
lifetime. Moreover, if an exported key expired, everything derived
from it dies.

[Bernard] (from slides): TEKs usually expire on the peer and server after the session ends

[Joe]: I think that this is a good suggestion. Maybe deleted is better than expired.

[Paul]: Agreed that expired is a wrong word.

[Hannes]: Is AAA-key stored on the local AAA server?

[Bernard]: It says only about expiration not storing

[Jari]: What about fast handoff? we use the same AAA-key?

[Bernard]: Need more thoughts on that. We have to guarantee the AAA-key freshness

[Paul]: Something about SA protocol: EAP method generates fresh keys
but then it is the SA protocol that is responsible of these.

[Joe]: (about slide 7) better EAP server and not AAA server

[Bernard]: not sure. Let's discuss on the mailing list

[Joe]: EMSK has a shorter lifetime than MSK

[Bernard]: the issue is that applications do not know the lifetimes of AMSKs

[Joe]: These are problems of applications and are not fixable by EAP

[Jari]: In theory we could negotiate all lifetimes. In practice, there
are limitations so I think the approach of Bernard is trying to use is
the usage of the session lifetime to regulate all lifetimes

[Joe]: Session timeout is very specific to AAA protocol.

[Bernard]: The idea is that we have a general timeout that could be a
session timeout or another but it is generated by AAA server

[Jari]: We can't describe generally but we have to look at the protocols that are used, Diameter or RADIUS

[Joe]: Disagree. There are things that are independent of that.

[Jari]: (about slide 8) Is it a maximum TSK lifetime or a minimum?

[Bernard]: Maybe this the minimum TSK lifetime



ISSUE 262: KEY NAMING
Text proposed in the mailing list
Some methods do not have EAP server name and use the authenticator
identity. Maybe there are some implicit requirements that derive from
this text

[Joe]: We should not have requirements on AAA server name

[Hannes]: Key naming discussion is confusing. What means key naming?

[Bernard]: The naming requirement derives from caching

[Hannes]: Naming keys you generate state

[Bernard]: It is needed to select exported keys

[Hannes]: To select a state does not require strings or names

[Bernard]: this is true but...(something lost)

[Hannes]: Key naming has nothing to do with what you are talking about

[Jari]: If you have a connection-oriented protocol you have state and
you don't need key naming. But for caching you need. None is using key
naming and existing systems use link-layer names. We could have
potential requirements in the future and this is also why we are
discussing name. Another question is which names we use.

[Bernard]: (about slide 10) there are implicit methods requirements in
this paragraph and we should be careful on this

[Pasi]: we are not interested in naming keys but in naming state. I
don't understand why we need to name keys but something else

[Bernard]: we are naming sessions and not keys

[Hannes]: short comment to Pasi. Half document talks about key naming
and half about Security Association. Another issue MSK is never
selected again, so it does not need to be named.

[Bernard]: we need to name it for caching

[Hannes]: it's the AAA-key not the MSK

[Bernard]: Good point.  We should make it clearer in the document




ISSUE 267: PRF NEGOTIATION
Bernard states the proposed resolution
No comments



ISSUE 275: AAA-KEY SHOULD BE DERIVED FROM AMSK
Bernard states the proposed resolution

[Jari]: there must be something in the KDF to have different keys for different APs

<Bernard added Generation # in the second bullet>

[Joe]: there is the application data. The first purpose of the AMSK is
not to have the EMSK around. We should discuss the requirements to
understand if these keys must be different or not.

[Hannes]: this key derivation can be used in some places and not in
others. This is not clear in the document. I'd suggest to add usage
cases.



ISSUE 277: DRAFT ORGANIZATION
Bernard states the proposed resolution
[Jari]: Security analysis and not requirements

[Hannes]: I'd like to see architectural issues pointed out, for
example how EAP is used in IKEv2 and some IEE examples. For people
that do not have IEEE background it's difficult

[Bernard]: Agree. This is missing

[Paul]: is the document a best practice? or a survey of architectures?

[Joe]: I'd like to see what are the expectations for EAP methods and
how the applications can use the keys exported

[Madjid]: I just want to know (if it possible) in a generic way how
keys are derived without IEEE or TLS details

[Jari]: we are trying to describe a system. We'll try to describe how
key derivation works: this part should be simpler.

[Madjid]: It's hard to read and the key derivation is only in the
appendix

[Jari]: it's an organizational problem and we are trying to
tackle. The purpose is to describe the security of the system

[Jari]: We are open to different suggestions to reorganize the doc.



ISSUE 278: LIFETIME OF KEYS INTERNAL TO EAP METHODS
Bernard states the proposed resolution
No comments



ISSUE 279: SA PROTOCOL REQUIREMENTS
Bernard states the proposed resolution
No comments

[Bernard]: the main challenge of the doc seems to be organizational




3. EAP STATE MACHINE, CHAIRS
----------------------------

[Jari]: Are there open issues?
no comments




4. AUTHENTICATED SERVICE IDENTITIES, PASI ERONEN
-------------------------------------------------

(slide 3) If D is compromised it can pretend to B

This is because EAP does not have a concept of service or NAS identity
Solution: the AAA server tells the client to which service it is
sending the key It is not the same thing of channel binding: the
difference is between "I believe" and "he claims" Method independent
framework for service identifiers. This method independent blob can be
carried in AVPs in EAP methods

[Hannes]: Good document and useful

[Jari]: Channel binding vs Authentication. Do people think this distinction is useful?

[Pat]: This is an interesting problem. IEEE has a group dealing with
fast handoff and this could be an issue because in this case the key
is not obtained from the AAA server.

[Someone]: If AAA server and X have trust relationship and X has a trust
relationship with Y, is this framework needed?

[Pasi]: Yes. With this framework we want to prevent that a problem
(e.g. a node is compromised) in a part of the system spreads in the
whole system.

[Yoshi]: PANA is also specifying service parameters. I think we need
to add to PANA this service parameters

[Pasi]: we decided not to include this in the document and eventually
specify in a separate document

[Paul]: why not change the direction and the client sends the
information to the AAA server and the AAA server confirms? For example
for SSID this could be useful.

[Pasi]: SSID is also carried by RADIUS




5. NETWORK SELECTION UPDATE, CHAIRS
-----------------------------------

Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt):
waiting input from IEEE WIEN next week

Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt):
to be sent to IESG

No comments




6. EAP PAX, T. CLANCY
---------------------

Changes due to comments during last meeting
Supports provisioning with a weak pre-shared key
Supports key management with forward secrecy using Diffie-Hellman

List of major changes from version 00:
        Address Crypto Concerns
        Protocol Implementation Issues
        support for HMAC-SHA1 and AES-CBC-MAC

Description of the message flow both in no identity protection and
identity protection cases

Implementation using FreeRADIUS and XSupplicant
Working on implementation for Windows XP supplicant

Comparison between PAX implementation timings: PAX, EAP-TLS, PEAP-MSCHAPv2

[Hannes]: EAP-TLS is unfair as comparison, you should use EAP-PSK

[Clancy]: We just used what it was implemented in FreeRADIUS

[Joe]: regarding TLS timeline, have you ran tests with session resume?

[Clancy]: without

[Joe]: it could be useful to compare with EAP-TLS with session resume

[Robert]: Considering the complexity of the code, for slower devices
this EAP method could be very useful

[Hannes]: Yes, it's good to think about performance and for example
memory space

[Jari]: How much interest is there? Who read the draft?
-> 6 people

[Bernard]: Are you requesting a standard track?

[Clancy]: Yes

[Chairs]: Who thinks we should do something like this?
-> 7 yes, 0 no

[Robert]: This is very leight EAP method. For example it could be
useful in bridges

[Bernard]: We should have a discussion and write something about that





7. EAP SMARTCARD, PASCAL URIEN
------------------------------

[draft-urien-eap-smartcard-type-00.txt]

EAP methods working with smartcards may conflict with purely software
methods Proposal: one EAP type (EAP-SC) for all smartcards

The EAP-SC model: three layers

1. The EAP-SC handling layer receives and sends EAP packets, selects a
   Smart Card handler, and passes packets to the Smart Card handler

2. The EAP Smart Card Handler layer handles the interface to the smart
   card and any EAP Method specific functions

3. The Smart Card executes Authentication Method functions


[Hannes], [Pasi]: EAP terminates in the smartcard itself. Why is it an issue?

[Pascal]: You have a conflict because you may need software methods
and smartcard methods for the same protocol

[Pasi]: If you are solving a software problem on the client why do you
need a new protocol?

[Pascal]: There is a conflict from a software point of view

[Jari]: I agree with Pasi and it seems to be other mechanisms to
tackle this method selection. People have implemented without nothing
on the wire.

[Pascal]: IMO the authentication server always knows if smartcard is
required or not

[Jari]: Are you saying that there is a need of communication?

[Pascal]: it's an issue for the client side that should not switch
from a method to another

[Joe]: I don't see the need. It seems an implementation side problem.

[Pascal]: I don't agree

[Hannes]: We have implemented EAP methods using smartcard and this was
not needed. You really need to describe which is the problem you are
trying to solve in order to understand

[Pascal]: It's purely a practical issue

[Pasi]: Smartcards are not so special to require a new EAP type code

---discussion cut----


[draft-urien-eap-smartcard-06.txt]

New support of EAP-TLS
EAP Smart Cards and EAP-TLS Security Claims

[Hannes]: The distinction between user authentication and computer
authentication is an identity issue

[Hannes]: I don't think this topic (implementation in SC) is related
to EAP WG and IETF in general

[Pascal]: If these devices are useful for IETF we should specify

[Glenn]: I read this draft and it seems an API specification and is
not for IETF. The implementation of EAP methods in smartcards is
strictly internal to smartcards