eap Mailing List: EAP WG minutes from IETF 65

[Bernard Aboba (bernard_aboba]

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 <aboba [at] internaut.com>
Jari Arkko <jari.arkko [at] piuha.net>

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.