Subject: [eap] design team minutes, jan 22nd

From: [email-masked] (Jari Arkko)
Date: Wed, 22 Jan 2003 22:59:17 +0200

EAP State Machine Design Team (ESTEEM) Meeting Minutes
January 22nd, 2003

Scribe: Jari Arkko

o A lot of progress has been made on the list regarding
   the open issues. This time we talked about the state
   machine more than the issues.

o John Vollbrecht talked about the status of
    the state machine work:

   - We have come far.

   - The new version (not in the I-D archive, only posted to
     eap-design) should correspond to the one Paul has done for the
     IEEE supplicant state machine. A link to the draft will
     be posted to the main EAP list as well.

   - John is happy about the status of the peer side. Some issues in
     the authenticator side remain, however.

   - Bernard: There are some issues how the authenticator functions.
     Conclusion: The authenticator means the same thing as in 802.1x.
     It does do basic EAP things, such as retransmissions.

   - John has a model on how passthrough works, but not quite ready to
     present to others yet. There's a passthrough method which in one
     side it looks like EAP, in the other side it looks like
     RADIUS. NAS is controlling retransmission and other tasks in both
     directions. The simple way to think of this is that a NAS mux
     talks to a method (possibly the passthrough method).

     Bernard: This is not quite right, mux does not get all the
     packets. It doesn't have type codes. John: has a wildcard type
     code.

     Jari: Are you thinking of allowing one method in NAS, then
     something else in passthrough. John: Basically yes, but it is
     really hard to get out of passthrough. Bernard: Thats ok because
     if you go to passthrough then you are saying that you don't look
     at packets.

     John: One problem I still have is that I originally thought Naks
     would not go to methods, but here I seem to have to send Nak to
     the passthrough method since AAA needs to know what methods have
     been Nakked. Bernard: It could be that the NAS gets a Nak, handles
     it, and goes to passthrough method as a result.

     Bernard: James has been stressing that we should focus on what
     goes on in the wire.

     Bernard: But the Nak might not go on the wire (between the NAS and
     the AAA), it could be for the NAS only. It could be a Nak of a
     method the NAS was running.

     John: At first you select a method -- send identity, send local
     method, have the AAA send its method.  The response comes to what
     ever initiated it. Bernard: I agree with that. John: What's the
     problem then? Bernard: If Radius initiates, the Nak would go then
     Radius. This is fine. But if the method was initiated by the NAS,
     the Nak would go to the NAS too. Not passed to the Radius. Then
     I'd suggest to go to radius and let it deal with the peer instead.

     DECISION: Who ever sent the request gets the response as well, be
     it the NAS or AAA or whatever.

     Question: But currently, the NAS sends Id-Req and response goes to
     the AAA. Bernard: But that can be defined as the response coming
     to the NAS, and it just forwarding it via EAP-Start to Radius.

     Bernard: To complicate your life a little further, NASes might be
     passthroughs for some methods and users but not for others.

   - Jari: Can an AAA proxy become a passthrough?  John: That's an
     interesting question. One of the questions if exactly where the
     EAP protocol chain can be broken out and terminated. Bernard: It
     can be broken anywhere where there are local methods. In EAP TLS,
     any node can terminate the method, including proxies.

     John: I've been thinking of Kerberos authentication with all
     proxies along the way. Bernard: I think we want to forbid
     this. John: Yes, we are starting to lose the knowledge of who are
     we talking to. Bernard: Yes, that's the basic problem with
     sequences and so on.  Also emphasizes the need for careful
     evaluation of the compound binding problems.

     Bernard: We could consider the question of where to terminate the
     EAP method as a RFC 2869 last call comment.

     Comment: Need to consider Nak as a valid response to the first
     method in the state machine.

   - We don't want the 802.1x layer to look at inside the EAP packet
     and decide things based on that.

o Keying

   - We should talk about Jim Burns' proposal for a key exchange
     method. Do we ever want to send keys in the middle of method, or
     only at the very end with Access-Accept?  Bernard: One problem
     with these attributes is that there never was a table in the
     RFC. So its not clear where they are legal or illegal. John: They
     are legal if no one says they are illegal. I think it wasn't the
     intent however when these RFCs were written. Its also a security
     issue whether this is a reasonable thing to do.

   - Bernard: This is all up to the RADIUS server. Say you send keys i
     the middle of a challenge. One of problems in RADIUS is that you
     never know if those keys were accepted. Certainly in DIAMETER we'd
     like all the keys to be mandatory. John: We need an acknowledgement
     of accepting the keys. Bernard: The problem is that there's no
     response to Access-Accept. John: The next Radius Request could
     be used for this.

     This is really a much greater issue of when attributes have
     been turned on and so on. Bernard: Yes it is. A problem
     is that radius can't tell that critical information couldn't
     be used. You never know. But DIAMETER does that.

     John: I'm still not convinced that you can't do this in
     RADIUS. DIAMETER is better in many respects, but not sure
     if it can do everything either.

     There are non-EAP reasons why AAA servers need to know whether
     e.g. encryption was turned on. For instance, this information may
     be needed for accounting. It may be according to the server's
     policy to disconnect if either eap or ip traffic encryption can't
     be turned on.

     Jari: Why allow in-method or in-sequence turning of encryption?
     Bernard: Agree with the in-method part. But in-sequence
     may be useful.

     Bernard: I believe there's a case for a link-status AVP.

     Bernard: It is possible to have keys in Access-Challenge.
     Currently they would be silently ignored. Jim's fix will extend
     current treatment to allow turning them on in other situations
     than at Access-Accept.

     We have to know the order in which things happen. In 802.1x, EAP
     Success is sent before keying is turned on. This does not
     correspond to what the RFCs say.

   - Bernard: I encourage everyone to read 2869bis and comment.
     Here's what it says: everything else processed prior to
     processing keys. John: But what does "processing" mean,
     does it have to be "turn on"? That's what Jim was working
     on, trying to figure what the interface ought to be.

   - Bernard: Part of the problem, to be blunt here, is that there is no
     keying attributes specification. I though Bill Arbaugh signed on to
     do it: It turns out the current key wrap is bad. We need a key
     wrap. Its not a simple problem. In diameter its better than in
     Radius since ipsec/tls protect better than radius shared secrets.
     Most people think its ok to send using ipsec/tls if its one hop. But
     what happens if there are multiple hops? John: Diameter server would
     not know if its doing ipsec, but it would know about tls. John:
     I fear Diameter is not going to solve the problem in the short
     term. And CMS is far away from ready. Bernard: I think that is
     an accurate statement.

     Bernard: 802.1x at least separated eap and radius. In 802.11i, it is
     much more intermingled, there are references to Radius all over the
     place.

     John: We need to make sure that Radius and Diameter both will
     be able to carry keys.

o Meetings

   - Anyone planning to attend 802.11a meeting in Seattle?  Bernard: I
     will participate. John: when is that? February 19th-21st. That
     would be the ultimate place to work out all the remaining