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

From: [email-masked] (Puthenkulam, Jose P)
Date: Wed, 23 Oct 2002 21:38:36 -0700

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C27B17.378E1D80
Content-Type: text/plain

Here is a white paper on some thoughts on making EAP exchanges secure. It is
just a framework for thought.

Thanks,
jose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Jose Puthenkulam
   Senior Software Engineer
   Emerging Platforms Lab
   Intel R & D
   Intel Corporation
   2111 NE 25th Avenue, JF2-58
   Hillsboro, OR 97124
   Tel: (503) 264 6121
   Fax: (503) 264 8154
   Email: [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2002 7:19 PM
To: [email-masked]
Subject: [eap] 10/23/02 Minutes of the EAP Design Team

Short minutes from today. I didn't have time to write down all the
discussion
on John's paper, so feel free to add items.

Jari
-------

Date: Oct 23rd, 2002

Present: Bob Moskowitz, Nick Petroni, Jari Arkko, Yoshihiro Ohba, Glen
          Zorn, John Vollbrecht, Paul Congdon, Joseph Salowey

1. John's position paper.

    - Was submitted, but bounced the list.
      He started to do state tables which
      assumes the methods can also privide
      information to the EAP mux. Clearly needs
      more work, but he'd be happy to pursue it.

    - There's a couple of main things:
      - It would be possible to map this back to the states
        that are in the state machine now. Though it doesn't
        make any distinction about methods, even identity
        is seen as a method.
      - Assumes policing. Some of the actions assume
        that policies will dictate certain things.
      - Starts to imply things about the API.

    - Bernard: This is fairly complete.
    - Bernard: There are two cases when you receive
      method X request. One, we are done and should
      change state. Two, we need further requests.
      In addition, there are error situations.

    - Bernard: If within a method, you receive
      another method, is this NAKked or silently
      discarded.
    - DECISION: NAK is better than silent discard.

    - Question: Is a failure of a method terminal?
      We could either terminate EAP, or allow
      continuation with another method per policy?
    - John thinks we should allow the latter.
    - Jari thinks we should not.

    - Question: is the treatment of final success
      or fail dependent on whether the previous method
      failed or succeeded?
    - Proposal: We need a new state for this.

    - Question: is there a global state, what has
      happened on all methods, useful maybe for
      reauthentication? How can reauthentication
    - Answer: Good question.

    - Jari: Why is not authenticated vs. nocurrent
      methods there?
    - Jari: Reformulated question: is Success / Fail
      illegal at the beginning?
    - Bernard: Maybe this is policy?
    - Jari: If we can avoid policy, we should.

2. Moving Forward

    o Drafts:

      - Bernard: I encourage John to write up this
        state machine with this draft.
      - Jari: Should we have an individual draft by
        John, or merge drafts to WG draft status.
      - DECISION: Too early now.
      - Bernard: It would be better if Brian and Nick
        could do another revision of their draft as well.

      - DECISION: Priorities are: 1) follow decisions 2) be complete 3)
follow 802
        format.
      - Jari: Need to capture current decisions. Bernard: We are tracking
        the issues.

      - Bernard: One of the open issues is described above

      - Yoshihiro: We also need to consider the passthrough state machine.
      - Jari: That can also be done as a separate draft.

      - DECISION: By the I-D deadlines, we will have the following:
        - 2-3 state machines
          - rfc2248 updated to -07
          - some solved issues
          - many unsolved issues
        - position papers and minutes will also be published

    o IETF-55 and where do we go from there

      - We will have a total of 4.5 hours and 2 slots.
      - On the first day, state machine is important
        and the issues are important
      - Second day is still unclear
       - What kind of method discussion we can have
         is under discussion.
       - John: Method discussion is key for EAP.
       - Bernard: We need to try to discuss issues in the methods,
         see if they are affected by state machine modifications etc.
       - Process for evaluating methods.
         Drafts solicited. Luca, Glen are writing something
	about this.
       - Glen: Cart is pushing the horse. Compatibility
         with 802.1x is not so important. Bernard: Tony Jeffrey
	views the 802 state machine as a way to suffle
	EAP packets around. The job of the IETF state
	machine is to decide what to do with the packets.
	Because the IETF state machine is link layer
	independent, it is at a higher abstraction
	layer. We will use similar format, but it
	is not the intention to force this state
	machine to comply with 802 state machine.

    o Continue with dt meetings after initial I-D deadline?
      - John: Not available next week.
      - Jari: We should continue.
      - DECISION: Meetings continue and next week we will go
        over the open issues.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

------_=_NextPart_000_01C27B17.378E1D80
Content-Type: application/octet-stream;
	name="EAP-MACs.ZIP"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="EAP-MACs.ZIP"

------_=_NextPart_000_01C27B17.378E1D80--

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 24 Oct 2002 05:07:36 -0700 (PDT)

Since everyone might not have Microsoft Word, in general it is better to
post using text if possible. If that is not possible, a pointer to a file
in Adobe PDF format is preferred. I'm told by our mailing list sponsor
(David Frascone) that pointers to files are strongly preferred to sending
files within the messages themselves, due to bandwidth constraints.

With respect to the paper you've posted, I have some questions:

a) Which of the problems on the EAP issues list is this a solution to?

See: http://www.drizzle.com/~aboba/EAP/eapissues.html for a list of
issues, or instructions for filing an issue.

b) Wouldn't this require existing EAP methods to be rewritten to use the
new Request/Response codes?

c) How are the keys to be derived with which to calculate the MACs?

d) What portions of the EAP header are considered mutable/immutable in
calculating the MAC?