Subject: [eap] EAP WG minutes from IETF 65

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Apr 2006 16:00:07 -0700

Here are the EAP WG minutes from IETF 65.  Please send corrections/comments 
to the list.

------------------------------------------------------------------------------------
Extensible Authentication Protocol (EAP) WG
IETF-65, Dallas, Wednesday March 22 2006
Room Metropolitan

Chairs:  Bernard Aboba <[email-masked]>
Jari Arkko <[email-masked]>

1. Administrative (Chairs)
   - Document status (see slides)

   The EAP WG has completed all of its work items other than the
   EAP Key Management Framework and Network Selection documents,
   both of which have completed WG last call.  This will be the
   last meeting of the EAP WG; the goal of this meeting is to
   close the remaining issues on these documents.

   Status of WG last call issues is available here:
   http://www.drizzle.com/~aboba/EAP/eapissues.html

2. Remaining EAP keying framework issues (Bernard Aboba)

   http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-10.txt

   (See also slides)

   Purpose of the presentation is to close remaining issues
   from WGLC.

   Five of six filed issues have been closed. One issue
   remains. The resolution of issue 317 is to focus
   on the externally observable behavior and avoid
   overspecifying internal behaviour that has led
   us to the debates on the list.

   Comments?

   Joe Salowey -- one concern that I have is the use of term
   "lower layer" which has not been clearly defined.
   Bernard agrees that there's been prior confusion
   with this term in another issue, and some of that
   still remains. Bernard thinks we need to take another
   pass to clarify the terms.

   Conclusion: Still need to confirm if the proposed
   text is acceptable on the list.

   Question if channel bindings text is sufficient in
   the document.

   Process point brought up by Jari: we are not committed in the EAP
   keying framework to solving the channel binding problem.

   Yoshihiro Ohba: Would channel bindings be pursued in
   other working groups. Jari responds that there is no
   plan at this point about where to address it. Time for
   the individuals to progress their documents, could
   consider recharterting an existing WG or doing a BOF.
   Bernard points out that having running code would
   help in convincing the community that the proposals
   actually work.

   Nit about group keying brought up on the list. To be
   corrected.

   Plan is address the remaining issues and then bring the
   document to a final WG last call during April.

3. Remaining network selection issues (Jouni Korhonen, Farooq Bari)

   http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-03.txt

   (See also slides)

   Purpose of the presentation is to close remaining issues
   from WGLC.

   Bernard: This item has been a long time on our charter and the
   purpose of the WGLC is to make clear what the working group wants
   to say in this matter.

   Ten open issues have been filed under last call. What we intend to
   do is to close these issues and publish the document.

   Jari's comment on sections 1, 2, 4 has been done. This includes
   cutting away all text on work that is in progress. Authors
   not sure if the latter was needed, however.

   No new draft revision published before the IETF because
   there were new issues brought up just before the deadline.

   Farooq's proposal on corrected terminology was posted on the
   list. Bernard thinks it would be useful to talk about the
   terminology in this meeting, because multiple SDOs are
   talking about this, and its hard to communicate without
   well defined terms.

   Basic problem is that we use the term "network" to mean
   many things -- prefixes, visited networks, home realms,
   roaming networks, etc.

   Most confusion is caused by selection between operators and ISPs,
   because its not well defined what it means.

   Access technology and access selection is fairly clear -- I chose
   802.11 and this particular access node.

   Comment - operator selection is a business term. Bernard does not
   think its clear -- for instance, in 802.11 is SSID operator
   selection, or is Farid's id selection it?  Or something else?

   Jari Arkko - we need to name these things according to the data
   item we select. For instance, SSID selection.  "Operator selection"
   is not well defined because we have no data item "operator" in the
   protocols.

   Pasi Eronen - yes we need a terminology update. Suggests network
   attachment point selection, identity/credential selection.

   Glen Zorn - I think we are talking about two different terms
   in network selection, visited and home network selections.

   Comment - Might be better to speak about home server selection
   because its not really a network.

   Jouni - Agree with these comments. Current draft mixes these
   terms.

   Another issue - current document focuses too much on
   802.11.

   Bernard Aboba - one of the issues brought up during IETF-64 was
   that the document does not talk about enough about the problems
   that come up with some of things that have been defined recently,
   such as draft-adrangi. In the Internet is that we do not know a
   priori if we can reach a given address; to find out you send a
   packet and see if you get a response. This is similar to what
   should happen with realms in network access. There's essentially an
   infinite number of them, which makes it hard to store reachable
   network identifiers in any one place. Some of these scalability
   issues should be addressed in the document.

   Glen Zorn - The document says that there is no experience on
   applying phone book mechanisms for wireless access. I do not think
   it is the main problem. With phone books you have a unique
   identifier, the phone number. In wireless networks you may not have
   such identifiers, since many of the identifiers such as SSIDs may
   not be unique. Bernard says that the phone book approach is
   used, but in a different way. You do not press a button and
   dial a particular network. You may attempt to go to a location
   where the book says there's network. Comments by others that
   some phone books do list SSIDs. Avi thinks this may be
   useful in wireless networks, because currently he can
   count the number of business partners with his two hands
   and feets. John Vollbrecht thinks that large consortiums
   have issues with unclear or unauthorized SSIDs. Hard to
   know of operator X is "X" or "X1" and if someone spoofed
   "X". This might be useful, but we can't count on it.

4. Generic EAP encapsulation proposal (Barany, Dondeti, Narayanan)

   http://www.ietf.org/internet-drafts/draft-barany-eap-gee-00.txt

   Purpose is to get feedback from the EAP community on this proposal.

   (See also slides).

   Looking at a model which may need two EAP authentications, one for
   pure access, another for "service" (such as mobility).

   Glen Zorn - Why do you need to parallelize the authentications. If
   you have no access, you are not going to get service.  The authors
   are looking at latency issues. Another issue is that in EAP the
   sequence number does not allow easily to demux where messages
   should go to.

   Requirement for this model has come from MVNO deployments that wish
   to have two authentications.

   Question - What is a service network, why would you need to
   authenticate it? Its L2 vs. L3 difference.

   Jari Arkko - Not sure if that answer clarifies it
   sufficiently. What's special with the number 2. Why not 15? You can
   run multiple services over the Internet, you could even have
   multiple types of mobility services if we are not talking about
   application services...

   Question - If you do access authentication, do you have IP address?
   No.

   Discussion about the seperation between device and user
   authentication. It is possible that different credentials are used
   for the two authentications.

   Discussion about sequential vs. parallel authentication and when
   either one could be done.

   Bernard Aboba - Is there a separate link between the MN and
   access/service authenticators? There's just one link. So there is
   no possibility to multiplex different links etc? No.

   Question - Can you explain the business model, why would anyone buy
   access from someone and service from someone else -- but I confess
   I come from the enterprise space. MVNO is cited as the prime
   real-life example.

   Jari Arkko - I'm willing to entertain the idea that someone
   needs two authentications. But there's different ways of
   doing it. You could design your link layer so that you can
   do this. I'm less comfortable with changing EAP or inserting
   layers to do this just to shoehorn two EAPs where one EAP
   fits. If you want to do things like authentication for
   mobility service, you could use IP protocols to accomplish
   what you need, e.g., IKEv2 EAP. Better idea than trying
   trying to design a new layer. Authors respond that
   they would have to do it in multiple link layers, so
   that's why they come to the IETF.

   Question - what is the significance of colocating the
   authenticators? In the simple case there is one authenticator and
   two authentication servers. Then you need GEE to separate which
   protocol run you are using. But if you have two authenticators,
   then you have a more complicated picture.

   Discussion about whether its possible that there's
   one authentication server which serves two authentications
   for the same user for different "layers".

   Yoshihiro Ohba - Problem should be solved by the
   layer under EAP. PANA for instance allows two
   independent EAP authentications to be done.

   Discussion about whether the proposal is 2, 3 or
   4 party protocol. Disagreement. Yoshihiro thinks
   that adding additional parties would make EAP
   architecture even more complicated.

   John Vollbrecht - I do not understand if the
   two authentications are needed to get access
   or if one authentication provides you something
   and the other something else. The answer is
   that both are needed. John notes that then its
   a sequence of EAP methods, at least in the logical
   sense, if not in the timing-sense. Then there
   is no reason why you couldn't have four or five
   methods. Why? I don't know - but why run two...

   Meeting run out of time and no further questions
   could be answered.

5. AOB

6. Meeting adjourned.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap