eap Mailing List: minutes from IETF-64

[Jari Arkko (jari.arkko]

Here are the minutes from IETF-64. We had some
trouble constructing these, given that one of the
note takers had a disk crash, but David worked hard
on his minutes and the mp3 recording of the session.
Please send corrections, if any, ASAP to me or Bernard.

--Jari

Minutes of EAP WG Meeting
64th IETF Vancouver, BC 
09:00-11:30 Nov 7, 2005  Salon 1
Chairs: Jari Arkko, Bernard Aboba
Minutes Editor: David Mitton (some edits by Jari Arkko)

Agenda Review

Presentation directory: http://www.drizzle.com/~aboba/IETF64/eap/
WG Issues webpage: http://www.drizzle.com/~aboba/EAP/eapissues.html

Document Status Review:
RFCs
       RFC 3579 aka "EAP over RADIUS" published earlier [Individual]
       RFC 3748 aka "2284bis" has been published earlier
       RFC 4137 aka "EAP state machine" published recently

In RFC Editor's Queue
       draft-haverinen-pppext-eap-sim-16.txt  [individual]
       draft-arkko-pppext-eap-aka-15.txt   [individual]
       draft-adrangi-eap-network-discovery-14 [individual]

Drafts
       EAP keying framework - in WGLC
       draft-ietf-eap-keying-08.txt

       Network selection problem definition
       New editors, new energy!

-----------------------------------------------------------------
Network Discovery and Selection Problem
 Jouni Korhonen, presenting
 draft-ietf-eap-netsel-problem-03.txt

Old EAP WG document updated to reflect current situation in 3GPP,
IEEE, and new references.  Minor cleanups throughout.

Proposal for Version 4 work:
- Update based on discussion
- Make Section 2 more network technology agnostic
- Improve consistency between sections 2 and 4
- Updates for 802.11u

Discussion - Scope of Draft?
- Is the problem limited to EAP?
- Limited to certain technologies?
- Limited to boot strapping?

Jari Arkko: There was useful discussion of the potential solution areas
and I don't want to see that limited to purely EAP layer.

Bernard Aboba: One of the hardest part is to knowing what the
appropriate use of EAP is, and there are problems with the use of AAA
that need to be discussed.

Glen Zorn: What does this have to do with EAP specifically? Other than
a handy place to discuss it.

Arkko: This is a problem that comes up often in EAP situations, but
the solutions do not have be EAP based.  It could be moved to another
WG.

802.11u Network Selection

802.11-05/0822r3 had requirements for selection.  One proposal is to put
NAI in Probe, AP probes AS, returns a result in Probe Response.

Comment: There no formal proposals in 802.11u at this time, just
presentations, so don't be quick to assume this is where the group
will end up.

More questions about the details of the nature of this probing.

Bernard: Coming up a level, we got here because there is a limit on
SSIDs and other things to select on.  There isn't a way for the AP to
know if a given realm is reachable. So we invented a sort of AAA ping
message to explore the proxy route. But there is ongoing discussion in
IEEE of other methods that might make this unnecessary.

Comment: In the TGu there is no statement supporting this function.

Steering of Roaming
- can we do something more efficent that doesn't depend on intential 
failures
- Is AAA sufficent?

Glen Zorn: This is a AAA Routing issue or even Layer 2 selection and has
nothing to do with EAP. We should not be addressing them in this group.

Comment: We really need to persue these issues, and we need a place to
discuss them.  So we have permission of the ADs to discuss them here,
but we would be willing to move to an appropriate WG as we progress.

Bernard: We started this trying to understand and evaluate
draft-adrangi-eap-network-discovery, and this is an archive recording of
the result of that discussion.

Comment: If we were trying to go to another group, we couldn't fit in
other groups which have narrower criteria.

Comment: We should start a BOF to discuss.

Glen Zorn: This group is not the right place.  Use IETF mechanisms like
a BOF to find a proper place.

Pasi Eronen: If the goal is archive the discussion. Then lets finish
the editorial task in this group.

Mark Townsley:  If there is no more work to be done, it could be done
as an indivual submission.  Could I get a sense of the room?
Is there more work to be done on the problem here in the IETF?
<some number of hands>
And how about the solution?  <some number of hands>

If so, then you should get some people together, submit a proposal for
forming a BOF and start that process.  But it sounds like EAP is not
the place for this.

--------------------------------------------------     [0:43:35]
EAP Key Management Framework - Bernard Aboba
 draft-ietf-eap-keying-08.txt

WG Last Call to expire November 30th.

Givens: Attacker can see, forge and replay all traffic, may be an
insider.  Goals: Mutual authentication, Freshness, Bindings.  Server
must not expose the keying material to anyone other than the
authenticator.

Reviewed characteristics of: IKEv2, 802.16e, 802.11i, PPP

Pasi: How likely is it for a AAA server to be sharing keys? Bernard:
The impact depends on the lower layer, but if the AAA server shares a
key, it potentially allows authenticators to masarade as the server.

Sam Hartman: What about roaming and a peers that don't know the AAA server.
Bernard: That is a problem, and we have to look at the chain of trust, and
after the authentication, whom has possession of the keys.

Sam Hartman: we shouldn't be analyzing all the problems of other
protocols.  Bernard: We are just describing the security
characteristics with respect to the goals.

Majiid: Are we discussing how to fix these protocols, we shouldn't.
Bernard: We want to know what the consequences are of removing or not
using optional features.

Pasi: We don't want to spend time analying combinations that people
don't use. Bernard: We have issues with Mandatory to implement vs
Mandatory to use.  We should expect that people will not use some
features, and should describe the consequences of not using those
features. There is a legal mandate for government applications to
secure their systems to FIPS compliance.

Pasi: What about the mechanisms described in key wrapping documents?
Bernard: There are issues that these solve and that's what the work is
for. But not everyone wants to use them, and that changes the
security value.

Key Caching

Comment: Why mention existing AAA servers instead of EAP servers?
Bernard: Describing existing implementations, caching is not mentioned
in current EAP documents, methods can have a cache, but the AAA lower
layer does not.

Parent/Child linkage:

Sam: If we require deletion of keys, what about fast reconnect
situations?  Bernard: Excellent question, we'll talk about it in the
next presentation.

Jari: Confusion on list about storing other parameters than
credentials. The AAA server doesn't know, only the EAP method really
knows.

Issues discussion:

Glen: If there are problems with terminology because of errors in RFC
3748.  Maybe we should try to fix RFC 3748, instead of creating new
work. Bernard: Don't we have that many errors, we do have some
confusing terms.

Conclusion: Continue issue discussion on the list and submit
reviews during WGLC.

------------------------------------------------------------   1:48
EAP Key Management Extentions - Bernard Aboba
 draft-aboba-eap-keying-extns-00.txt

AAA caching

Bernard: We defined some interfaces, then we discover they aren't good
enough.  These come from LPC vs RPC semantics.  When we defined that
the EAP layer doesn't cache, we didn't understand all the
consequences.

Pasi: Redefine the standalone case to include another layer. Bernard:
Define an internal layer that caches between the two.

Comment: We could cache at a lower layer.  Bernard: Yes, we could, but
we are discovering scenarios where that is not good enough. Some
methods are trying to generate key state for multiple authenticators
and run into cryptographic independance and binding issues.  We need
to redraw some of the diagrams and figure out how to make these
different situations work.

Jari: Not trying to solve all possible ways. Only need to make sure
that we understand some ways it could be done. Bernard: We want to
understand the implications so we don't exclude something some people
might want to do.

Comment: Do we need understand neighbor graphs and distribution?
Bernard: None of the keying is dependent on this. Just to show the
implications and that this information is out there.

-----------------------------------------------------------  [2:12]
EAP Handover Support - Madjid Nakhjiri
 draft-nakhjiri-eap-ho-00.txt

This draft is a discussion of how people are using the EAP framework,
what they are trying to do, and given what they are doing, what
requirements make sense or not. We should also try to decide how much
of the work belongs here or can be done elsewhere.

Wireless mobility goes beyond the original EAP model. Issues with key
distribution between server, authenticators, mobile nodes.

Sam: Why cannot the access node be an authenticator?  Handover. But
you are introducting another trusted party into the trust network, and
you have to convince us doing security reviews, that simpler scenarios
don't work.

Majiid: I didn't design them, these are the IEEE keying models.
Comment: Can we understand (not guess) why they want to do it this
way?  Comment: This is a matter of centralizing the authentication,
and moving functions from the the 100s of base stations to a smaller
number of NAS boxes.  Cost reasons and centralized management and
control.  Pasi: This is not any different than the WiFi switch
architecture, with dumb antenna and a central switch.  In the WiMax
case they seem to be documenting this protocol. Whereas, many cell
networks have similar protocols but they are propretary so we haven't
gotten to bash them.  Jari: So they made the mistake of telling us.
We need to move on.

presentation continues...

Majiid: I'm throwing out some suggestions and asking if this makes
sense? Some it can be done in this group or some other.

Jari: I think the discussion is very valuable.  I see two tracks, one,
seeing if the Key Framework has the right stuff, and then, continue
with review of specific proposals and see if another WG is needed.

Bernard: Does the keying framework preclude things? Well we've seen a
bunch of problems today.  So we'll go and fix those.  And then see if
we can do what we need to do.  There are little assumptions that seem
okay, but when put them alltogether they cause things to break.  Some
of them we've had in there for awhile and we didn't understand their
full effect.

----------------------------
Wrap Up

Network Selection

Strawpoll
  Who cares? 11 yes  Not: 0

  Bernard: The history behind this draft is another individual
  submission (draft-adrangi), and the IESG asked whether it was
  compatibile with EAP? The EAP WG document attempted to analyze the
  problem space so that we could answer the IESG's question.

  Cares: Ambition level: 3=0, 2=0, 1=6

  Some people want to move this out of EAP,  but Jari points out that 
we can
  only vote for this group.

  EAP: 0
  Individual: 3
  BOF: 8

  Ambition level seems to be on the problem side, not solutions

  Glen: Try to address the problem that
  draft-adrangi-eap-network-discovery solves.