Subject: [eap] Minutes of the 10/16/02 EAP Design Team

From: [email-masked] (Bernard Aboba)
Date: Tue, 29 Oct 2002 19:29:36 -0800 (PST)

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, October 28, 2002 2:02 AM
To: Bernard Aboba; [email-masked]
Subject: minutes of meeting, oct 16

Date:       Wednesday, October 16, 2002 and Wednesdays thereafter
Time:       8 AM PDT, 11 AM EST
Phone #:    425-706-7766 or 800-456-7312
Meeting ID: 124843

Agenda

- 802.1aa Comment resolutions
- University of Maryland issues for resolution
- Bernard's position paper

Present: - Paul Congdon
          - Bernard Aboba
	 - Tony Jeffrey
	 - Jari Arkko
	 - Nick Petroni
	 - Robert Moskovits
	 - Yoshihiro Ohba

o Tony Jeffrey and IEEE

   - An issue has come up when Tony tried to implement the changes they
     agreed in the last ieee meeting. The primary problem is that request
     identity not necessarily the first message. They originally planned
     to change the way EAP exchange was initiated. Now the plan was to
     send message back to the radius server, to get it to initiate EAP.

     Then they realized there's a major problem with this: this was not
     just for initiaing eap, but also to find out if there's a live 802.1x
     device on the other end of the link. This will lead to calling the
     radius server every time there's a change on link status

     Bernard: This also comes up in 802.11.

     They've overloaded the initial message to signal 1. start and 2.
     establish that there's someone to talk to.

     Tony, Paul, Bernard: The easy way is to keep the existing approach,
     but with the change that the first message can be any message, not
     just request identity. There are two choices: 1. any message selected
     by the radius server, or 2. the message is built-in. Typically Radius
     server will respond in the same way anyway (unless there's a MAC
     address lookup which we can't have with switches).

     At the switch end you would configure a message type for the
     initial exchange, and that would be used for starts within the
     port. Typically this would be Identity Request, but could also
     be something else

     Someone: This would reduce the number of RTTs to the radius
     server

     Bernard: In the future we may have the first message of a method
     hold a challenge; this would be in conflict with this.

     Do we need to give a type, or a message? Does the authenticator
     know the method, or just send a canned bytestring?
     DECISION: Still have to insert the current identifier. The MIB
     object is essentially a type and text.

     Jari: What about roaming, does this work? Bernard: Yes. The default
     is today's Identity Request. We could start with a protected
     method in this new system. This would provide privacy up to the
     radius proxy. Everyone on the area must be using the same
     first method.

     The main change is in RFC 2869, explaining how this would
     work. RFC 2284 does not need to be changed.

o Other issues while Tony was on line

   - Bernard: Do you like the approach we've been planning that once
     a method begins, we lock to this method state and do not accept
     other methods until its done? Tony: OK.
   - Is it OK if Notification can be sent at any time? Yes.
   - Question: Is there a clean management of id values when multiple
     things are coming around, e.g. Notification and a method? Answer:
     This is from the server and responded as normally. So yes. Problem
     with Radius a la 2869, however.
   - Do you Tony like the approach we've been planning for the
     documentation of the state machines? Tony: sounds good. formal state
     machines would be good. Bernard: the format will be as close to the
     802.1aa format as possible.
   - Question: When does a supplicat discard a success or a failure?
     802.11aa chose not to address this, but we will handle in IETF.
   - Bernard: In IETF #55 we probably don't get the state machine
     completed yet. But hopefully within 1-2 months there's a state
     machine draft.

   - DECISION: Tony and Paul try to figure out the exact text for their
     procudere in the first item of the minutes and get it  reviewed.

   - Bernard: What is the 802.1aa schedule? Tony: Depends on comments,
     fastest track sponsor ballot before Christmas.
   - Bernard: Sounds like we are on a similar schedule

   - 802.1aa has developed some MIB material, which can be
     posted later as an informational Internet-Draft
   - RADIUS attributes needs to be a new maintenance
     revision of 802.1x
   - We are probably going to move 802.1x support to the
     Diameter draft, as there is a separate draft on EAP AAA
     now.

   - Bernard: Any other issues in IEEE & IETF relationship?
   - Tony: Things are going pretty well at the moment.

o Talk about the issues U of Maryland brought up on the mailing list:

   - We need to nail down the interface stuff before we proceed. John's
     proposals helped here.

   - How is informaton passed mux-method?
   - DECISION: Use variables.

   - How is information passed between methods? Open.
   - What about keying information? Open too. For instance,
     another method could be following tls, uses cipher determined
     in tls.
   - Everyone should have access to the IDs (potentially
     several).

   - Ordering: How to decide the policy, how dows policy
     affect the protocol? Bernard : This is not visible on the wire.
     Lets talk about this later. Sequencing and tunneling
     issues do show up on the issue list. One issue is cryptographic
     binding, talking to the same endpoint all of the time.
     To fix that, we need a way to push down the keys and
     use them, using some sort of MAC that shows I know
     the keys for all previous methods.
   - One concern with interfaces is that we no longer allow
     implementations to be stupid. Bernard: we should document
     the implications.
   - Bernard: All agree that these issues need to get done.
     we should focus on interfaces for the next couple
     of weeks.

o Bernard's position paper on primitives

   - There is a picture about the architecture and layering.

   - Primitives:

     - get_identity
       . Might cause an send_identity invoke.

     - send_identity
       - Jari: Why is there no answer_identity? Bernard: Can't
         do it ; relates to Jessie Walker's issue. Maybe affected
         by the expected next method, as a policy thing. But you
         could get it wrong.

     - complete_method, informs the result.
       - Jari: Why does this remove all filters, what if this particular
         method does not want anything run after it (e.g. tunneled
         EAP TLS)?
       - Bob: We need authenticated success/failure. Bernard:
         We've gone from a single method to tunnel/multiple.
         Jari: Does someone actually use sequences of methods or
         only tunneling? Answer: Yes, both are done.

     - request keys, provide keys
       - Jari: Are these just keys or also the cipher suite?
         Bernard: Probably we need a separate primitive for that.

   - Bernard: Do we like this set of primitives? Are primitives a good
     thing?
   - Jari: Yes -- need more details though.
   - Jari: Some of this has to be standardized, like the use of the
keys.
     Other parts is implementation dependent.
   - Bernard: Its a basic question how the cryptographic binding gets
done.
     Would this be in 2284 bis or not? Jari: Lets do it later.
   - Do we also need a notification primitive?
   - DECISION: Bernard: Yes, we do.
   - Jari: who sends success/failure?
   - DECISION: Bernard: I think we decided that its the eap layer.
     Perhaps we need to give a parameter for Complete that
     says whether to send a success/failure or not. On AAA, we also
     need to know whether to send Access-Accept or not. It seems like
     the indication is necessary.

o Closing remarks
   - We need more position papers around these issues.