EMU Notes. Friday Aug 1st, 2008 EAP Tunnel method requirements draft-ietf-emu-eaptunnet-req-00.txt 5 people have read the draft. Joe, Had requirement to protect EAP headers, value unclear. Proposal to remove the requirement and address any other specific cases that require protection. Bernard: More about implementation of EAP rather than EAP methods. Checking length fields & only handling supported types. Charles Clancy: Experience implementating of EAP method with EAP header prtection was horrible. Chair, ok, general agreement. -- Credential provisioning. Chair: Requirement to support credential provisioning. It means a lot and instead should be for flexible exchange inside tunnel sufficient to allow this, but not define specifically the method. Proposal is to move the requirement to a 'may' or use case. Bernard: This requirement is about allowing/making possible. How do I know if a method has made it possible? What is it about the method that makes it extansible to enable credential provisioning. Chair: I think there are examples of thing tat have already done this. Bernard: So it's really an requirement baout extensibility. Chair: yes Steve Hamm: We already have this extensibility requirement. Jabber, DAN: Who's credentials? Chair: Often credential a client can use. Sometime a trust group. Chair: Move out of a requirement to example text within extensions requirement. Dan, If tunnel is secured can other things be provisioned. Chair, I think that's a little out of scope of the discussion -------------- Channel Binding chair: Current doc requires channel binding. With incomplete discussion text. We have additional work item. Should refer definition and discussion to the channel binding document. Just have a requirment that points to that doc. Bernard: Agree. I object to the statement that RFC4362 requires it. Not the case. It is up to the WG to figure out. --------------- Chair: That's all of review so far. From Bernard. Klass: What about the MUSt is the serf credential revocation checking? Problems with revocation list chekcing in a lot of implementation. E.G. when you have self signed certs it is useful. Does it make it more sense to have a should. Chair: We want a method capable of supporting this. Tends to be useful, but there are operational challenges. Up to deployer to determine they want to support it. Klass: What EAP methods currently support it? Would this requirement prevent people implementing methods. Don't want people avoiding the IETF because its too hard to implement. Chair: Have a SHOULD requirement to implement this in EAP TLS. Concerned that if we remove the requirement that the work won't be done. DeKok, If its a security thing, make it a MUST. Klass: put in security consideration. May limit the use of the RFC. Steve hamm: If implementation must support it, we can wait until tunnel method is define to address this. Paul hoffman: Text Doesn't talk about CRLs only OCSP & SCVP. Don't want to require a second method. Chair: The motivation for going with online protocols is that they provide a way to support this revocation checking. Paul: If you're not online you can't. Bernard: You can through the EAP channel, but you don't have IP. You can run OCSP through EAP. Paul: Easier to pass small CRLs along with the cert. Doesn't work for large CRLs like DoD. Most people don't pass around the CRLs. Most IPsec can handle CRLs in the message. David Mitton: Any text desxcring the service provided to the inner EAP protocol? Chair: There are use cases describe what the tunnels provide, such as confidentiality & integrity. David: E.G. cryptogrpahic binding against the EAP messag IDs. E.G. Client had different idea of message ID to server. They should be equivalent. Bernard: Have noticed issues. EAP methods that don't supprt fragmentation, but would have to within a tunnel. Some only support fragemetaiton during the tunnel setup and not within a tunnel. Have requirement that the tunnel method can handle it. Chair: Can you explain your issue. David: In peap a client generates ID of 15. Server receives message with ID 8. Hashing accross the entire message breaks the authentication. Had to change the protocol. Chair: Requirement to not monkey with the eap exchange? David, Bernard: yes. Bernard: Requirement is to transport inner EAP method without modification. David, DJ: Yes. Chair: Can we have some more people review? David, Kausha, bernard agreed to review further. ------------- EAP-GPSK Charles: Its moving thorugh ISG land. Addressed Pasi's review. Issue: Assumes MAC output is the same as the input length. Not the case for AES-CMAC-256 : 256 in 128 out. Do we care. DJ:Yes Chair: Yes. Obvious example that it doesn't care. Charles: Need to be careful covering all the changes. DJ: The example that works is an imprtant nist compliance algorithm. Need it to work. Chair: How many want it changed: No:2, Yes: Many. DJ, Pasi will review the changes. Chair: Discussion on the stateles sprocessing of messgaes? Charles: Yes, goal is to reeduce the amount of state held by the client. In the second round, the server sends all the information, so the clinet doesn't need to hang onto it. If the client isn't maintaining the information and the server changes it, is that a problem? Should we err on the side of minimal state or maximal consistency. Chair: Background is that we went thorugh external security review. Main change was a request to make it stateless. Charles, Can't be completely stateless or you'd have replay attacks. Not a big deal, in favor of least edits. Leaves it up to the implementation. Can't see a valid attack. DJ: We value message size over state. On air bits cost money. Charles: Document is currently in favor of minimizng state, not message size. Chair: Take it to the list. Requiring state to be maintained is going back on the review output. Who has enough info to have a poll?- none. Take it to the list. ----------- EAP Channel Bindings. draft-clancy-emu-aaapay-01 mechanism forcarrying diameter AVPs in many existing EAP methods. draft-clanc-emy-chbind-01 Describes to how to use this transport for channel bindings. Desscibes scenario on slides. Bernard: Fuzzy compare is troubling. Doesn't work. Information structures differently. So have to tranfer information in exactly the same format. Any lack of fidelity and will fail, Guranteed to not work. Chair: Explain fuzzy compare. Charles: Beacons and probe responses. Pack in a diameter AVP. E.G. 802.11 Ciphersuite IE. Alper: What info does the DB hold? Charles: What IEs the AP should hold. In the enterprise case, DB would contain contractual case. Alper: Can't know what roaming partner comparisons. Bernard: Created radius so we didn't need to track what happens in 802.11. Now it must. DJ: Troubled with client visiting thorugh different technolgies, 3GPP, .16, .11. David Mitton: Observation. Put in some channel binding, didn't implement it because we couldn't get the infor from the blue box into the client. 802.11 doesn't define useful info and couldn't get it thorugh the client interfaces. But server can't figure what the box might be telling the client. For crypto comparison, it has to be down to the bits. Bernard: This is a change to driver models. The informatio has to be passed up. All the driver makers have to agree to pass stuff up in the correct format. Or it won't work. Charles: A new O&M section talks about this. Alfred Hones: Small terminology concern with fuzyy comparison. More basic problem is that fuzzy logic is an established term that is combination of statistics and formal logic. Output answer is statistical. Not yes/no. Profile matching would be a more appropriate term. Chair: Need specific examples. See examples in 802.11 & 16. See what makes sense. What data needs to be captured. what comparisons need to happen. Charles: Goes through slides. Question? Who is validating the channel binding method? Is is the method, server or AAA? David Mitton: This is more of a policy decision than a compare. Bernard: Need to be clear the value of checking in the AAA rather than the lower layer. 802.11 already checks BSSID, MSID and RSNIE in the 4 way handshake.Most useful to store the comparison data in the format in which it will be compared in the AAA. Charles: Don't have anything in the document ot valdate information between AAA and NAS. NAS could lie in both directions. Bernard: By the time it's gone through the proxy, it's unchekable. The data would have been laundered through the proxy. Charles: Comparing what the NAS says to the client, not what the NAS says to the client. We could do that. Glen Zorn: Each of the distinctions we discuss is artifical. It doesn't help to munch together the AAA and EAP protocol. David Mitton: Interesting layer entanglement is going on. It is not in 3748 that the EAP method has access to this information. There are side channels but they arn't part of 3748. Charles: So we try to keep things EAP specific and not AAA in the document. David: Not talking AAA at lower layer. The AP is not party to the EAP, he's a proxy. The AAA has to work with the info in the EAP messages. Compare with dial-up, can include phone number with calling station id in NAS. Etc. Charles: Conclusion: Need more work. Biggest change - get rid of fuzzy comparison, replace with more explicit text. Talk about not only what the nas says to the peer but what it says to the AAA. Bernard: Doc needs to make a better case for doin this at all. Sending the diameter cost attribiute is good. Addresses theft of funds. But might try to put in a use case section with cases scary enoughto justify doing it. Charles: Can expand the use cases. Bernard: Yes, include money theft issues. Charles: would like to adopt as WG item. Chair: Want another iteration & review. Still outstanding issues. Including the motivation for the channel bindings. ---------------- EAP-PWD. Glen Zorn: How many read it? 2. Third version. Added password preprocessing method indication to the EAP-pwd-ID/req. Null and microsoft proprocssing requsts were added to the document. Like to know of any other methods so we can add it. Goes through slides.. Mystery Questioner: Shouldn't you have string prep method. sasl-prep. Chair: Prep is to prep into the storage format, like salted hash. Mystery Quetioner: Look at sasl-prep. E.G. Unicode formats. Glen: If in unicode should prep in that format. DeKok: Is this a point for IANA allocaiton. Glen: Yes. We are requesting. But can't do salted unix password for example. ------------ One more item. Chair: ITU-T Recommendation X.1034. Guidelines on the the EAP based auth and key management in a data communication network. Can we get access to the document? Zachary (guy from ITU): Liasion was approved by SG17. Need to make sure it was sent. Tim Polk: Send us the document. We'll start looking at it immediately. Send it asap. Zachary: OK. doc was attached. Tim: Don't worry, send the doc, not the liaison. Glen zorn: Procedural question. Is it going to makea difference if we review it, or is it going to stay the same. Tim Polk: It's been approved, But we can send liaison back if we see real problems. They asked for our input, so I assume they will use it. Bernard: Do we have the doc? Tim: No.