IETF-87 EMU (EAP Method Update) Meeting Minutes TUESDAY, July 29, 2013, 0900-1000 ---------------------------------------------------------- Chairs: Joe Salowey Minutes: Nancy Cam-Winget Version: 1 ---------------------------------------------------------- Agenda - Covers note well - Document wrap-up: - Mutual Crypto Binding on IESG telechat by 8/15 - Tunnel Method in IETF Last call ends 7/30 ---------------------------------------------------------- Tunnel Method Discussion ---------------------------------------------------------- Exporting Certificate Fields (Stefan Winter) Joe: Handling multiple subject names in the certificate for peer-id and server-id. Proposed resolution is to export both CN and SAN names change 'or' to 'and'; alternative is to make primary name a subject alt name and if not present use something like CN or define priority order. But former is the preferred resolution. Sam pointed out that we do have a section covering cert validation that does specify how to match names; but that's independent of identity export. Sam Hartman: still doesn't understand what the Peer and Server ID get used for... 1st time it gets used may raise security holes and inconsistencies. Concerned about when names are exported when they're not authenticated, they bring security concerns. If allowing someone to use identity that's not been authenticated, it is bad. Suspicion is that we have a similar issue here (as there is in ABFAB); we may be OK, but 1st time it gets used it'll become an issue. If someone's planning on using it, they should come up and describe the use case. Joe: can see potential issues, but with these particular identities they are authenticated. Sam: just because it is in the certificate, doesn't mean its used to establish an identity. If checked DNS name for validation, doesn't mean that the other names are credible. Joe: we can try to adapt the text. Sam doesn't think its worth updating. Stefan: raised the issue because the cert in Phase 2 would go to this... but if that is the case, then it may not be a big issue. If there's an easy way to fix it, why not do it now? Jim Schaad: there is 1 issue to discuss and can help Sam. Today, we export the IDs and don't say where we got the IDs (e.g. inner method or certificate) so not sure source of ID so that may be more interesting for Sam to look at. Sam doesn't care. Robin Wilton:if look at certs used for human identities assurances come from that process. So may not need to address it here Leif Johansson: Sam do you care about the key to name binding. Sam's not convinced its just that. Joe: may have diff methods inside so tracking the identities may be harder; so there can be an issue. Inclination is to just move the text to 'and' and see if there's an easy way to bring out this particular authentication issue forward. Joe polls: room is split between leaving the same text vs. changing it to an 'and'. Will move this proposal to the reflector. -------------------------------------------------------------------- NAI reference (Stefan Winter) For TEAP, it's a question of identifying which identity trigger to be used or what identity is used where especially as it is exported. There's no good place to fix this so its either to not fix names exported by inner methods or to add text along the lines of "Ongoing work clarifying the usage of UTF-8 in the NAI in [draft-radext-nai] will update or replace [RFC4282]" Sam: asks what to fix in TEAP. Stefan states to not reference RFC4282. Sam: is concerned about TEAP's encoding of the identities from inner methods. A TEAP implementation needs to make it clear what character set is being used, else don't use it... if its not obvious, then it needs to be written into the spec. Joe: tends to agree with Sam. If inner methods export identity, TEAP needs to know what it is; as diff methods may use different encoding methods and can't change it for each method at this point but that will not work (practically). Stefan: That is why fixing it in EAP core would be better to force all methods to conform. Sam: do we specify identity encoding in TEAP Phase 2... if not, then we should. How does password work? Joe state that they are in TLVs. Stefan: the password one does say its UTF-8 but others don't Sam: if its inner methods sending the identity, the spec of the inner method is burdened of defining that encoding. If the spec is poor and doesn't say, then its hard to enforce it as such. But its our job to ensure that in what we specify we need to clarify that. Joe: we can't change the inner methods at this point. Sam: agrees that we can't change in general Joe: we could reference ongoing work with NAIs, and note that it may be insufficient for now. But not sure it's the focus for the TEAP document, but OK if we just make mention of it. Stefan: regarding Phase 2 usernames, if there's no spec then "it's too bad". Sam: no, it just means its an implementation problem. In many cases, there are other means than just failing. Leif: perhaps its just a should vs must Sam since we don't specify it; suspect Microsoft's implementation is UTF-16 there's no reason we should say its wrong. Joe: to Stefan's point we need to do it for at least peer and server IDs Stefan: not quite my point, but its about the inner Phase 2 identities Sam: somewhere we should say that TEAP identities should be UTF-8 Stefan: my point was that, to always use UTF-8 for EAP identity packets Sam: don't care where we say it, TEAP or EAP though should be global Stefan: agrees on global EAP applicability Dan Harkins: doesn't EAP already say not to use the identities anyway? They recommend that authentication protocol to ask again for the identities so that outer response can be thrown away (used for routing only) Stefan: but routing component still needs to know encoding so that it can route Dan: but that's independent of TEAP Stefan: right, which is why its broader than TEAP Joe: we can't make statements of overall EAP, but we can do it within the scope of TEAP (e.g. outer EAP identity is governed by RFC EAP).not sure what to do here other than to note Leif: sounded like Stefan/Sam were volunteering to write text for this Stefan: bullets on slide should be fine, but also do work on EAP in general to fix this Joe: we can take this to the list Jim Schaad: we ought to go thru document that have strings have the right encoding as there are other things that need to be clarified. Joe: good point ---------------------------------------------------------------------- Error Messages (Josh Howlett) Error messages not fine grained enough: incorrect pwd; acct locked; backend database offline, etc Sam comments: some application implementations can generate much better error encoding at the server, for instance MSFT implementations would indicate it as TEAP already. Joe: so we could add more error codes if we need what to add Josh: haven't been given it a great deal of thought and these error conditions apply to other EAP methods too, so would be OK to make it more general Joe: if someone can do this we can fold it in Sam asks Josh if they can do this today... response: maybe Jim: do you want this propagated out of the method or within TLV Sam: TLV would be fine Stefan: inside TEAP TLV would be good enough and probably best Joe: asks if there're objections to add more error codes? No objections made... asks Sam and Josh to send suggestions to the list If we can resolve comments then we can be done! ---------------------------------------------- Closing EMU WG will stay open until RFCs are published. There could be other things we could be working on but Joe doesn't think they are major enough to keep the WG open. List will stay active Some work includes: - Channel bindings for existing methods: EAP-TLS, EAP-SIM, EAP-AKA, etc - Work on updating EAP methods with channel binding support Sam believes its not simple to add the channel binding support as there are issues and challenges especially with existing methods; would help to work with others but believes it's a lot of work. Joe: had some discussions of name encoding. Its an area that's ill defined in EAP and needs to be clarified and better covered. Its not trivial to approach so discussion will be needed but not necessarily in this WG. Joe asks if there are any other topics to discuss... none provided. Meeting is closed.