Re: [Emu] [saag] Feedback on Salted EAP draft
Kathleen == Kathleen Moriarty kathleen.moriarty.i...@gmail.com writes: KathleenI meant to send the link to Dan's draft: Kathleen https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01 Kathleen Long week... I have briefly reviewed the goals behind this proposal and a sketch of the details but have not done a technical review of the proposal. The underlying goal is important and valuable. This issue is the same issue that was behind my response to your AD review of the oauth dynamic registration draft. The more we can do to make it possible to use deployed password databases with more modern security, the more we will be able to employ that modern security. However, take careful note of section 5 of the draft. Assuming that you can get positive technical reviews of the proposal, this draft seems to solve an important problem that would be valuable to solve in the EAP community. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
Hi. My life has been hectic, and I completely dropped the ball on this! Thanks for doing this. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
Alan == Alan DeKok al...@deployingradius.com writes: Alan The idea was to allow *provisioning* of the Alan Response/Identity. Automatically deriving it from the Alan method-specific user identity is just as bad as Alan automatically using a 3GPP identity. Unfortunately in contexts like ABFAB, you're only going to have one username. I appreciate that there are environments where you need a different outer username, but I think we want to be moving towards anonymous outer usernames derived from the realm, and I do not support a spec that would make that more difficult. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Right place for ABFAB ephemeral keying
Hi. At the most recent ABFAB meeting I brought up the idea of adding ephemeral keying to ABFAB. This would provide the following: * Protect the EAP conversation between the peer and NAS (initiator and acceptor in GSS terms) * Provide a key to protect ABFAB negotiations * Prevent the EAP server or proxies between the EAP server and NAS from observing the resulting session This would help defeat fingerprinting by passive observers as well as minimize the damage that a passive server could do cooperating with the home EAP server. This is more valuable for ABFAB used in protocols like NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used within an TLS session for IMAP, XMPP or SMTP. Stephen thought the general idea of protecting ABFAB sounded good but would prefer that we get better protocol re-use and suggested we look into protecting EAP in general. I was dubious of that but suggested protecting Kerberos GSS in general as an option. After trying to work through how to protect either EAP or Kerberos, I've mostly concluded that I don't know how to get significant protocol re-use. However I do agree with Stephen that it would be better that get protocol re-use if we can still implement relatively quickly and meet all of the above protection goals for ABFAB. So, here are my thoughts on EAP and Kerberos: EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run between the peer and EAP server. We want PFS between the peer and NAS. The endpoints are wrong. We could insert a layer similar to ERP (the hokey produced EAP Reauthentication Protocol) between the peer and NAS. It's been a while since I've looked at ERP, but I seem to recall that ERP runs between the peer and an entity in the visited domain although it does have specific NAS support. That approach would be OK for ABFAB assuming it could be implemented efficiently. It would be a bit ugly because you want to start using the ephemeral key well before EAP has concluded. However, for lower layers that do complex keying after EAP concludes, it's probably the wrong approach. Also, ERP took a long time to specify. I don't want to commit to astandardization effort that complex. Kerberos. I was considering trying to share some tokens for ephemeral keying with Kerberos. keying wants ephemeral keing within a GSS mechanism. You could do that for Kerberos, although you'd need to take advantage of the not-widely-implemented extension to the magic checksum used by GSS for channel binding and (in that magic extension) other extensions. In ABFAb the framing would be different because our context tokens have subtokens. However we could use the same PDU. Except for two things. First, Kerberos probably would be happier with an ap-req and ap-rep extension than a GSS mechanism level extension. Secondly, Kerberos might well want to use pkinit data structures and possibly even run a stripped down client-server version of pkinit for the ephemeral keying. That's way too expensive in terms of implementation complexity if you don't already have a pkinit implementation sitting around. my conclusion from all this is that the right place to do ephemeral keying for an EAP protocol is in the lower layer and that unless I got something wrong or missed an alternative, ABFAb should do its own mechanism. Can anyone see a good way to get protocol re-use here? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)
Martin == Martin Stiemerling mls.i...@gmail.com writes: Martin Sam, Martin On 08/24/2013 03:41 PM, Sam Hartman wrote: Martin == Martin Stiemerling martin.stiemerl...@neclab.eu writes: Martin Hi Sam, Martin On 08/14/2013 10:16 PM, Sam Hartman wrote: Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: Joseph [Joe] Retransmission and timeout behavior for EAP is Joseph discussed in the EAP RFC 3748 Section 4.3. Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap) would be really unhappy if EAP method specs started discussing timeouts. Martin It is not about the EAP timeouts for whole messages, but Martin timeouts for fragments are not defined in RFC 3748 and must Martin be defined somewhere, as well as, what happens if timeouts Martin are exceeded for fragments. If an inner method supports fragmentation, then each fragment is a whole EAP message, in your terminology quoting RFC 3748. Martin So, for the unexperienced EAP people like me, TEAP is the Martin inner method? TEAP is running within EAP. *sigh* I'm sorry, I used the wrong terminology. Inner method doesn't come up here; that would be a case where say you were running EAP-AKA inside TEAP. Rephrasing to apply to your situation. If an EAP method supports fragmentation, that fragmentation is handled by the method. That is both fragmented and un-fragmented messages within the view of the method are whole messages, as considered by EAP. We see a similar situation with IP and ethernet. Ethernet (at least the version I learned about back when ethernet was simple) doesn't support fragmentation. Each IP datagram, whether it's a fragment or not, is a whole ethernet frame. As it happens, ethernet doesn't provide end-to-end service, and for a bunch of other reasons tdhat don't apply to EAP, you need to talk about retransmission at the IP layer as well as to some extent at the ethernet layer. However, with EAP, the EAP layer provides a reliable end-to-end service and entirely takes on the retransmission task (unless EAP itself is running over a lower layer that takes on retransmission and sets the EAP retransmit timeout to infinite). A method can fragment, but unlike IP, the fragmentation mechanism is entirely disjoint from retransmission. There are probably inefficiencies here because of that disconnect. however, EAP is not trying to be an efficient transport. And handling retransmission on the EAP side of the boundary and fragmentation on the method side side of the abstraction boundary provides valuable benefits for EAP. Like the state machine between the method and EAP can be lock-step without the method ever triggering an event. That's quite important for the way people have grown to build EAP software. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for draft-ietf-emu-eap-tunnel-method
Stefan == Stefan Winter stefan.win...@restena.lu writes: I think this is too detailed. The error codes MAY be used. Full stop. Whether you can is a complex policy and implementation discussion best hidden behind a MAY. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] last call for draft-ietf-abfab-eapapplicability-03
I wanted to make sure that people in emu are aware that the EAP applicability statement update for application authentication is in IETF last call. --Sam ---BeginMessage--- The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Update to the EAP Applicability Statement for ABFAB' draft-ietf-abfab-eapapplicability-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ballot/ No IPR declarations have been submitted directly on this I-D. ___ abfab mailing list ab...@ietf.org https://www.ietf.org/mailman/listinfo/abfab ---End Message--- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
OK. Based on your description of how peer and server ID are used, I have no concerns about 3.4. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call on draft-ietf-emu-eap-tunnel-method
Alan == Alan DeKok al...@deployingradius.com writes: Alan Alan DeKok wrote: This is a WG last call on the draft-ietf-emu-eap-tunnel-method document. Please post reviews, comments, feedback, etc. to this list. The WG last call will last two weeks, until February 26. If there have been no substantive comments or issues, we will take the document to IETF last call. Minor editorial issues can be resolved then. Alan There have been no comments during the last call period. We can Alan therefore close the WG last call, and move the document on to Alan the next step. Uh, hello? I raised some comments in a message dated Feburary 23 with subject Comments on draft-ietf-emu-eap-tunnel-method, , a few of which I consider substantive and would appreciate a response to those comments. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I think draft-ietf-emu-crypto-bind is ready for last call
There's an outstanding comment asking for a change to the ascii art. Besides that I believe we've addressed the comments and generally improved the draft. I think it's ready for last call. I do suspect we'll collect some more comments and have some clarifications after last call, but I suspect last call is the best way to collect those. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] crypto binding: why did I want a survey of methods
Hi. I've included a survey of tunnel methods that have made it to RFC and TEAP. It's quite possible that people want to cover more tunnel methods in the summary (LEAP, PEAP, EAP-TTLS v1). People who want to supply text are welcome to do so. After looking at it, I don't feel comfortable volunteering to do the inner method summary. For the more modern methods the answer tends to always be yeah, nothing wrong there. Now, the method itself may be weaker than you'd like, but the mutual authentication and key handling tends not to be of particular note. At least that seems to be true for the PAKE methods, for GPSK and for revised AKA. Note that is an initial guess, I don't have enough confidence in that statement to go write it down in the draft, and I'm not convinced it's all that useful. As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets more complex. EAP-SIM has some significant challenges with mutual authentication and I think with key generation. Being able to summary more than what is in the eap-sim security considerations section would involve a lot more operational knowledge than I have. I don't even know where to find documentation for EAP-MSCHAPv2. I'm strongly suspecting it's got problems, given its age and attachment to md4 and rc4. However, the mschapv2 PPP extensions got away with a one sentence security considerations section, so it's definitely not just summarizing already current security analysis. So, I don't think what I could do with inner method surveys is going to be helpful enough to write up. I'm dropping that section but if text emerges within the WG I'd be happy to include it. I think though that we're doing a good enough job with security considerations sections for post-RFC 3748 EAp inner methods that we don't need such a summary. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Comments on draft-ietf-emu-eap-tunnel-method
First, the document has been improved a lot in its clarity since the last time I read it. I'd really like to thank the editors, Jim and everyone else who gave comments for some excellent work. TEAP is by far the best EAP method I've ever reviewed, and I think security of EAP conversations would be significantly improved if people implement and deploy TEAP. Section 3.4: Does the server_id depend on whether the identifier is actually authenticated? That is, let's say the server is using a certificate but the client has no way to validate the certificate back to a trust anchor. However, the client uses some strong inner method and EMSK-based crypto binding to verify the server. Does the subject from the server cert make its way into the server ID in this case? Is it important that implementations get binary identical strings for server_id on both sides of the conversation? I think the text in 3.4 is sufficient that you'd get the right security properties out of the identity, but I suspect different implementations could get slightly different encoding etc. I have never used peer id, server id or session id, so I'm not sure if anyone cares about that. 3.5: old: tls_unique = tls_unique for the phase 1 outer tunnel as defined by [RFC5929]. new: tls_unique = tls_unique for the phase 1 outer tunnel at the beginning of phase 2 as defined by section 3.1 of [RFC5929]. rationale: The quantity described in section 3.1 of rfc 5929 can change when there is TLS renegotiation. This should avoid that. Section 3.8-3.10: All of these sections involve peer services in the terms of draft-ietf-abfabf-emu-crypto-bind. I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind applies quite strongly here. In particular, the peer MUST track whether it has authenticated the server. There's text repeated at various points in the TEAP spec that tries to say this, including some text in 3.8 and a hint at 3.10. I think this needs to be more unified. In particular I propose that: * A new section 3.11 titled Mutual Authentication for Peer Services be added: Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers need to mutually authenticate the server before these peer services are used. TEAP peers MUST track whether mutual authentication has taken place. Mutual authentication results if the peer trusts the provided server certificate belongs to the server; typically this involves both validating the certificate to a trust anchor andconfirming the entity named by the certificate is the intended server. Mutual authentication also results when the procedures of section 3.3 are used to resume a session in which the server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC present (section 4.2.13), then the session is mutually authenticated and peer services can be used. TEAP implementations SHOULD Not use peer services by default unless the session is mutually authenticated. TEAP implementations SHOULD have a configuration where authentication fails if mutual authentication cannot be achieved. An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how mutual authentication is achieved, only some of these parties may have confidence in it. For example if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who have achieved mutual authentication need to be considered when evaluating whether to use peer services./t * Section 3.8-3.10 explicitly refer to this new section. Some of the text about server authentication already present in these sections can be removed. * The channel binding TLV and the request-action TLV should also refer to 3.11. Section 4.2.7: Replace the definition of data with The data field contains a channel-binding message as defined in section 5.3 of RFC 6677. Will the channel binding data (client to server) ever be outside of a request-action TLV? If not, it's probably worth pointing this out. There doesn't seem to be a way for a server to request channel binding. If that's true we should probably add the following: Since a server cannot indicate a desire for channel binding, clients that have channel binding data to send SHOULD include channel-binding TLV in a request-action TLV if mutual authentication (section 3.11) succeeded. section 7.3: Please update
Re: [Emu] Review - draft-ietf-emu-crypto-bind-00.txt
Jim == Jim Schaad i...@augustcellars.com writes: Jim As was pointed out to me, the subject message on the message Jim had the wrong draft name (even if the version number was Jim right). Thanks for the review. I've addressed all the comments except: 1) I'm asking a co-author to help with your recommendations about ascii-art 2) 5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented Jim and get right. There is an easy argument that servers can have a policy configured about what inner methods can be used, but imposing it on the peer and making the configuration be server based can be problematic. I think that this issue probably deserves more text. How is the Jim configuration updated and transferred to the peer. The list of bullets is at the end of the section in a recap. I did add a sentence to the paragraph about peer policy pointing out that it's difficult to configure this policy. The difficulty of this sort of peer configuration is one of the main reasons I think EMSK-based cryptographic binding is important. So, I don't have any good answers. I don't think making the configuration server-based is particularly tricky; I think getting any EAP configuration at all beyond the minimal to get things working to the peer is the hard part. I'd ex pect most peers only interact with one EAP server. Even when peers interact with multiple EAP servers the configuration already tends to be server specific. 6. In section 3.2.4 - then condition 3 need to tell me where condition Jim 3 is - what section? There's now a parenthetical defining condition 3; all the numbered conditions are references back to 3.1. I think with the parenthetical added the text is clear without adding a section 3.1 reference to each numbered condition. 8. In section 3.3 - can the intended intermediary be on the other side - Jim that is between the NAS and the authenticator rather than the peer and the NAS? This is not clear from the text It's always between the NAS and the home server. Added clarification sentence. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Tweaking EAP (RFC 3748)
Alper == Alper Yegin alper.ye...@yegin.org writes: Alper On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote: Alper == Alper Yegin alper.ye...@yegin.org writes: Alper Hi Sam, Please also share this discussion with EAP WG and EMU Alper WG mailing lists. That's where the EAP expertise is and they Alper should chime in, given that you are proposing to modify EAP Alper applicability statement. The eap applicability statement update is a charter item of ABFAB. We've agreed it will be last called in EMU. Since it's a work item of abfab, it should be discussed on that list. You're certainly free to let people know that the discussion if taking place, although we've done that several times before. Alper Sam, Alper The type of changes you are talking about are well beyond the Alper applicability statement changes that ABFAB is chartered to Alper make. First, I definitely encourage you to involve anyone in any IETF WG discussion you believe will help form a better consensus. So, absolutely, encourage people who you believe should join the discussion to do so. I am a bit confused by your message, because I'm not discussing changing EAP, only discussing how some issues that seem relatively likely to come up will influence applying EAP authentication to application authentication. My intent is to document existing, potentially hard to understand aspects of EAP so that people can better apply EAP to their applications. Thanks, --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Help reviewing auth48 channel bindings diagrams
I'd appreciate it if someone could review the diagrams in section 5.3 of http://www.rfc-editor.org/authors/rfc6677.txt and confirm that those diagrams match the text. Once I get a confirmation there I think we're ready to approve the channel bindings RFC. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind
Jim == Jim Schaad jim...@augustcellars.com writes: Jim Sam et al, Jim 1. In section 1 after the Classic Tunnel Attack figure, I believe there are Jim three methods listed as possible mitigation strategies, however I don't Jim understand how the second one - a sufficiently strong inner method - could Jim possibly be a mitigation by itself. The three I see are 1) Policy 2) strong Jim inner method 3) Cryptographic binding. I actually was intending to describe cryptographic binding in two sentences; I've re-punctuated the text to indicate that if the inner method is strong enough you can do cryptographic binding. I believe I've addressed your other comments in an upcoming draft. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
zhou == zhou sujing zhou.suj...@zte.com.cn writes: zhou To my understanding, right prior to finishing tunnel establishement, EAP peer zhou and EAP Server(print server in the server insertion attack case) should have zhou exchanged channel binding with integrity protection by key only known to EAP zhou peer and EAP server (MSK in this case), well, I actually think this happens after tunnel establishment and after the inner method. So, after the print server learns the MSK. As I read draft-ietf-emu-chbind nothing forbids this. Certainly the existing implementations of channel binding I'm aware of work that way. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New draft on mutual crypto binding problem
Hao == Hao Zhou hz...@cisco.com writes: Hao Sam: Hao This is a well thought and well written draft, it covers a lot of background Hao and aspect of the attacks and mitigations. However, I have few comments: Thanks! You listed a set of drawbacks to EMSK-based crypto binding. Hao A. Mutual crypto-binding required the use of EMSK, not all existing EAP Hao method generate and export EMSK. It will also break intermediate AAA Hao servers. More importantly, it would only work for an EAP method that Hao generates keys. Part of the goal of Tunnel Method is to protect weak Hao authentication or EAP method, this would not benefits them. These drawbacks to EMSK-based cryptographic binding are documented; thanks. Hao D. Enforcing server policy would be another good way to go, if server can Hao demand tunnel method only, eliminate the chance of inner method MSK being Hao sent to the attacker. As discussed in the draft, you actually need a number of conditions beyond just that. However I agree server policy is another important mitigation, which is why the draft recommends it. Hao 2. I am not sure Mutual Crypto-binding is a good term, as the existing Hao crypto-binding is already mutually authenticating the peer and the server. Hao Maybe more accurate to be called Crypto-binding based on EMSK or Extended Hao Crypto-binding etc. I think of mutual cryptographic binding as crypto binding that provides defense against these sort of attacks (and personally don't consider existing cryptographic binding to really qualify as mutual.) I think though that describing this new mechanism as EMSK-based cryptographic binding is good. We may have other mechanisms that meet the security goals of mutual cryptographic binding and it is always desirable to separate mechanism from abstraction. I've tried to start that transition in the next version of the draft. Thanks very much for pointing this out. Doubtless we'll have another round of improving terminology. Again, thanks so much for your comments. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] on draft-hartman-emu-mutual-crypto-bind-00
Jim == Jim Schaad i...@augustcellars.com writes: Before the outer MSK has been computed, yes. Before the inner MSK (the one you need to attack crypto binding) has been computed no. Also, note that the RADIUS server only knows about the inner method, so it will transport the inner MSK as soon as it believes the inner method succeeds. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] A review Re: [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt
Joe == Joe Salowey jsalo...@cisco.com writes: Joe So, is your concern with using only MSK crypto binding with an inner EAP authentication method used to authenticate an unauthenticated/poorly authenticated tunnel or is it more specific to the nea-pt-eap method? Joe For the first concern it may be sufficient to discuss the issue in the security considerations. Sounds good to me and that is my concern. I see no reason EAP-PT needs more text than what we did for the cb draft. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] A review Re: [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt
I don't believe that existing crypto binding is adequate for NEA's needs as discussed in draft-hartman-emu-mutual-crypto-binding. Unfortunately, though, I'm not sure that tls-unique helps enough here. If the outer method actually does provide server authentication as deployed, then tls-unique is adequate. TLS-unique is preferable to crypto-binding because it allows you to determine whether you're talking about the right tunnel in the scope of the inner method--prior to doing the NEA assessment--rather than in the scope of the outer method. (Also, I'd assume this method does not generate a particularly useful key, so crypto binding is not that helpful) However, if you're depending on something other than the outer method for server authentication, then TLS-unique is not good enough. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Updated secdir review of draft-ietf-emu-chbind-15.txt
Stephen == Stephen Hanna sha...@juniper.net writes: Stephen The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen address almost all of the comments in my April 13, 2012 Stephen secdir review. I do have one remaining substantive comment Stephen on this latest draft and two non-substantive ones. Stephen Substantive Comment --- Stephen The last paragraph of section 9.1 points out a security Stephen problem with implementing channel bindings using EAP tunnel Stephen methods. If the EAP tunnel method terminates on the Stephen authenticator, the channel bindings can easily be defeated Stephen by the authenticator. While that's true, nobody terminates Stephen the EAP tunnel method on the authenticator today. In the Stephen EAP model, the authenticator is not trusted so terminating Stephen the EAP tunnel method on the authenticator is a bad idea Stephen for many reasons. For example, the authenticator would then Stephen have the ability to bypass protected result indications and Stephen to bypass all the cryptographic protections provided by the Stephen tunnel. Sometimes there is value in having the inner and Stephen outer methods terminate on different servers but both Stephen servers must be trusted. The authenticator is not. So Stephen there is no big security hole here, unless you have already Stephen opened an enormous security hole. It's ironic that this Stephen document which attempts to close vulnerabilities caused by Stephen malicious authenticators ends up subtly suggesting that Stephen people open a much larger vulnerability! Stephen I would recommend deleting the end of this paragraph, Stephen starting with the sentence that starts Even when Stephen cryptographic binding. I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say you should only establish trusted tunnels, because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] ð´: Re: I-D Action: draft-ietf-emu-chbind-15.txt
zhou == zhou sujing zhou.suj...@zte.com.cn writes: I don't really understand how that would be possible. If a fresh MSK and EMSK are generated per session, which we'd expect in a good EAP method, they need to be generated from something. So, I'd need to better understand what was happening if we had an EAP method that only had an MSK and EMSK internally. However, if that were the case I'd consider something EMSK-based while also considering whether it really made sense to add channel binding to that EAP method. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
zhou == zhou sujing zhou.suj...@zte.com.cn writes: zhou Hi all zhou In section 9.1 One attractive implementation strategy for zhou channel binding is to add channel binding support to a tunnel zhou method which can tunnel an inner EAP authentication. was zhou expected to introducing implementing channel binding on zhou tunnel, but was sudden to turn to cryptographic binding by zhou Tunnel methods sometimes use cryptographic binding, and began zhou on weakness of tunnel method with cryptographic binding, zhou especially on a specific (or typical) implementation with MSK. zhou In my opinion, these are two different topic, better in zhou separate paragraghs; and the first topic needs some zhou explanation, pros and cons, why not adopt that implementation zhou since it is attractive. I appreciate your desire to analyze the proes and cons of of tunnel methods. I'm nervous about expanding the scope of this document to do that because I believe it would add delay. Also, I'm confused about whether a general discussion of tunnel methods and channel bindings belongs in the security considerations section of this document. The explicit structure of that paragraph was called out for WG review prior to IETF last call; also that structure was present in IETF last call. I do not wish to wait to reach consensus on general comments about proes/cons of implementing channel binding with tunnel methods prior to approval of this document. Thus I prefer the current text. zhou Also, on tunnel method with channel binding, I think there is zhou some point unclear. zhou According to zhou section 4.2 The channel bindings MUST be transported with zhou integrity protection based on a key known only to the peer and zhou EAP server. section 6 The channel binding protocol defined zhou in this document must be transported after keying material has zhou been derived between the EAP peer and server, and before the zhou peer would suffer adverse affects from joining an adversarial zhou network. zhou To my understanding, channel binding exchange happens after a zhou MSK is derived between EAP peer and EAP server, and before MSK zhou is transported to authenticator. Channel binding can happen before or after the MSK is generated, but effectively needs to happen after some key is generated. zhou If not, for example, after MSK is transported to zhou authenticator, of course authenticator can control the channel zhou binding exchange. I would expect that the key used for channel binding integrity would be cryptographically independent of the MSK. I've not analyzed a method where the MSK is used for channel binding but this is done prior to transport to the authenticator. That's probably safe, but it seems like a bad design strategy because it seems needlessly fragile. So, I'd be nervous about that strategy and would recommend independent keys for channel binding. zhou I think that is why the EAP cryptograhic binding draft was put zhou forward. If it is made clear and MUST that MSK zhou transportation to authenticator happens after channel binding zhou exchange finishes, I don't think an extra crypto binding is zhou necessary. I disagree. I'd ask you to take a look at the slides I presented at IETF 83. I think they are more clear than draft-hartman-emu-mutual-crypto-binding at the moment, although obviously we will update that draft in the near future to reflect your comments and those of others. zhou and to make it clear I suggest EAP server transport MSK after zhou it has obtained explicit response from EAP peer to authorize zhou the action. That would be a change to existing EAP methods in some cases. That sort of change is out of scope for draft-ietf-emu-chbind. It's true that channel binding benefits from protected success indications and the current draft-ietf-emu-chbind does discuss that. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt
This version includes a large number of changes mostly to respond to the secdir review. I'm not entirely sure that Stephen Hanna will be happy with the changes in section 9, but I'd like to start there and see where we are. I think it's a good idea for WG members to review these changes. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-ietf-emu-chbind and username
I have no problemdocumenting why we do not do so as an example of privacy in sec cons -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Alan DeKok al...@deployingradius.com wrote: Sam Hartman wrote: I'd like to take a step back and ask why you'd ever want to channel-bind user-name in the first place? I guess the theory is that your EAP method supports channel binding but does not have a well-defined concept of peer ID or support identity protection/transporting method-specific identity? I think that situation isn't widely used. My proposal is that we stop recommending channel binding to user-name rather than documenting the issues associated with doing so. I would document why channel binding User-Name is a bad idea. Or, why it's useful only in certain limited circumstances. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] draft-ietf-emu-chbind and username
Steve Hanna did a secdir review of draft-ietf-emu-chbind. One of the issues he raised is a privacy concern with section 8. He points out that we recommend using the user-name attribute in channel binding. The concern is that if a server checks user-name in i2 against user-name in i1, then a NAS might be able to get an EAP server to act as an oracle for privacy protected identities. That is: 1) Peer identifies to NAS as @example.com 2) NAS thinks peer might actually be b...@example.com. 3) NAS tries that in user-name. 4) If it's not b...@example.com then channel binding fails. He suggested documenting this issue. I'd like to take a step back and ask why you'd ever want to channel-bind user-name in the first place? I guess the theory is that your EAP method supports channel binding but does not have a well-defined concept of peer ID or support identity protection/transporting method-specific identity? My proposal is that we stop recommending channel binding to user-name rather than documenting the issues associated with doing so. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Review of draft-ietf-emu-eap-tunnel-method
1) TEAP extends TLS RFC 5077 In section 2, TEAP discusses using phase 2 TLVs to include a TLS session ticket and an associated secret key. RFc 5077 only permits session tickets to be sent using the session ticket message. I believe that this is an extension to TLS that would need to go through the TLS working group. My preference is to remove TLS tickets sent via a manner other than the session ticket handshake message. If support for this is needed a better solution that does not involve changing TLS would be to provision a key for use with a TLS preshared key ciphersuite. 2) TEAP server is separate architectural element from inner server So, in section 2 the document says that the TEAP server and inner server are separate architectural elements. However, in section 1 a design goal was avoiding MITM attacks. To meet that goal and to have an architecture where these servers are separate, a lot more clarity is required around what a MITM is and what is an acceptable intermediate. I also suspect significant security analysis will be required on this point. Let's start by coming up with a clear definition of what a MITM is for this protocol and work from there. Section 7.3 is inadequate. It does not clearly explain who is involved in the trust relationship. IN particular, does the peer need to trust the intermediate, or do the inner servers need to trust the intermediate or both? I think it depends for different vulnerabilities. In order to understand the architectural implications of this I'd like to ask those who want to support this architectural separation to go through every reference to MITM or man-in-the-middle or mutual authentication in the document. For each reference, answer the following questions: A) Who is negatively affected if the attack is possible or the security claim not maintained? (eap server, peer, intermediate, combination) B) for security claims especially those about inner methods. Which parties need to confirm the claim in order to avoid the harm identified in A above? I also think we need clarity around mutual authentication and what that means especially when looking at compositions. 3) Section 3.2: resistance to MITM attack The specification refers to inner methods providing resistance to man-in-the-middle attacks as if this is an RFC 3748 security claim. I assume this refers to the discussion in section 7.4 of RFC 3748. I don't think that claim is strong enough to provide secure composition of inner methods with anonymous ciphersuites. This is related and possibly a superset of the problems discussed in draft-hartman-emu-mutual-crypto-binding). Clearly checking the certificates is an inadequate solution for anonymous TLS ciphersuites. 4) Section 3.2.2: overly much detail on TLS workings I think that having something called a PAC which is really just a TLS session ticket is undesirable. I don't think we need a new name for TLS concepts we're reusing. I am concerned that we specify so much information about how TLS session resumption works. What if future versions of TLS change that? What if our spec is inconsistent with TLS? I recommend we remove most of the information about server and client TLS session resumption and fall back to full vs abbreviated handshakes. 5) Section 3.3.3: confused I'm confused when I read section 3.3.3 on protected negotiation indication. I don't understand when an intermediate result TLV is or is not required for the peer and server. Also, shouldn't the crypto binding TLV always be required here? 6) Section 3.3.3: please require peers reject EAP success without protected negotiation. I think it is very important that we mandate peers implementing TEAP MUST not treat an EAP success packet prior to the peer and server reaching protected result indication as successful. When peers do this (as many do with existing methods) it permits several bid-down attacks. Se the new text in one of the most recent channel bindings specs for an example. 7) Section 3.3.3: How does a peer do channel binding What should a peer do if it wishes to perform channel binding and server sends back a protected success? Request-action seems inefficient for this because the first message is the channel binding request coming from the client to server. 8) Examples with section 3.3 I think that section 3.3 could benefit from several examples: 1) A peer wishes to use a client certificate but wishes to hide its identity and thus use renegotiation. The server requests some inner method in the first phase 2 message before the client can start renegotiation at TLS. Show an example flow of how this works out and how the parties get back in sync. 2) A peer wishes to use an inner eap method even when the server is happy to offer success in the first message. Show how many result indications are required. 3) Show how channel bindings interact with the result indications. 8) Section 3.4: what is a peer ID? Section 3.4 needs a reference to
Re: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind
Jim == Jim Schaad i...@augustcellars.com writes: Jim 3. 3.2.3 or 3.2.2 - If you had a non EAP method, and it Jim derived a key (just like a good EAP method). Is there any Jim reason why you could not do the cryptographic binding? Other Jim than it is not currently defined in one of the current Jim tunneling methods. One could see that it could be defined as Jim saying after you do this, then perform the same binding as any Jim key deriving EAP method would do,. I guess. I don't know that key expert is really defined for the non-EAP inners in a well-defined manner. But yes, I think something like this would be a good idea, although I'm not sure it is practical when compared to just forcing EAP inner methods. Jim 4. Section 3.2.4 - Item #4 - did you mean that it MUST prevent Jim an attacker from downgrading the binding from mutual to just Jim MSK-based? Also if the down grade occurs, do you still want to Jim claim that it is still mutual if step 4 is downgraded? The Jim current text implies this to me and that seems wrong. I'd love to discuss this with you in person if you're available. Jim 5. Section 3.2.4 - last paragraph - the last sentence confuses Jim the heck out of me. And everyone else; it's wrong:-) Will propose fixes to this and other comments. Jim 6. Section 4.2 - I don't understand why things like doing Jim channel binding require that a mutual authentication be Jim present. I can understand a statement that the peer MUST have Jim doing an adequate job of authenticating the server, but I am Jim less clear why the server needs to have authenticated the Jim client. Thus for example I think that cryptographic binding Jim should be sufficient to deal with these cases. (i.e. Tunnel is Jim authenticated to certificate and mutual auth is tied to the Jim tunnel). I think there's an assumption that EAP always provides peer authentication (although sometimes to an anonymous identity, isn't semantics fun?) so mutual auth and server auth are synonyms. And draft-ietf-emu-chbind has required mutual auth since well before I started working on it. I didn't re-evaluate that requirement. Jim Jim Jim ___ Emu mailing Jim list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New draft on mutual crypto binding problem
Dear Hao: I was pleased to hear your analysis of areas where mutual crypto binding may be tricky to deploy because I would like to accurately describe this problem space. I believe the draft covers most of the points you raise but I will definitely incorporate your feedback. I was a bit frustrated though that you proposed simply focusing on certificate validation without responding to the concerns that the draft raises in that area because I put a fair bit of time into analyzing that problem space and I was hoping to try and explain that there are no easy answers. I hear that you are concerned about the complexity of EMSK-based cryptographic binding; I'm guessing you'd like to make rapid progress on your draft. However I'm concerned when I think we may be discarding an option like EMSK-based cryptographic binding in favor of an option that we believe doesn't cover a number of deployments that we've decided in our requirements analysis are important to us. I think both of our options have merit. Would you be willing to get together with me and Dacheng before the EMU meeting to work on a design for EMSK-based cryptographic binding in your method and to work on understanding what's required to get the most out of certificate binding? I'd like to have a well-informed discussion about the complexity of EMSK-based cryptographic binding, the discussion of complexity of certificate validation and the environments where they can both function. I'd appreciate your help in getting to that point! I'd also be interested in working with anyone else on this problem. Currently I'm available Monday morning, Monday during lunch, Monday during the first afternoon session. It also looks like I have a fair bit of availability Tuesday. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Call for Agenda items
Pascal == Pascal Urien pascal.ur...@gmail.com writes: Pascal The goal of the presentation at the IETF 83 in Paris is to Pascal push this draft as an Informational RFC. Hi. I'm glad you want to publish this work as an RFC because I believe it's valuable and I'd like to see it an archival form. I'm supportive of efficiently publishing it as an RFC. I remaind confused because I don't understand how presenting the draft again to EMU will help that. Are you hoping that emu will adopt the document and we'll publish an informational rfc through emu? If so, I'm confused because I don't think that's in our charter. If you're hoping for an informational RFC not through EMU (either independent stream or IETF stream), how does the presentation help your goal? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Call for Agenda items
Hi. I'm confused. I'd like to understand why you'd like to present this draft? What response are you hoping for from the EMU working group? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Security considerations text for draft-ietf-emu-chbind
Hi. I'm posting a new version of the channel bindings draft in response to AD review comments. I've been requested to develop security considerations text in response to attacks I wrote about on the list. Here's the text I'm including in the new draft. Comments are welcome. I don't know if Sean will simply issue the IETF last call and allow us to comment on this text during the last call or if he'll seek comments on this text before the last call. Either way, you should send comments on this new security considerations text now if you have some. At the bottom of section 9.1 I've added: This trust model is a significant departure from the standard EAP model. In many EAP deployments today attacks where one NAS can impersonate another are out of scope. Channel bindings brings these attacks into scope; the system as a whole needs to be analyzed to evaluate cases where one NAS may impersonate another and to evaluate the impact of this impersonation. One attractive implementation strategy for channel binding is to add channel binding support to a tunnel method which can tunnel an inner EAP authentication. This way, channel binding can be achieved with any method that can act as an inner method even if that inner method does not have native channel binding support. The requirement for mutual authentication and key derivation is at the layer of EAP that actually performs the channel binding. Tunnel methods sometimes use cryptographic binding, a process where a peer proves that the peer for the outer method is the same as the peer for an inner method to tie authentication at one layer together with an inner layer. Cryptographic binding does not always provide mutual authentication; its definition does not require the server to prove that the inner server and outer server are the same. Even when cryptographic binding does attempt to confirm that the inner and outer server are the same, the Master Session Key (MSK) is typically used to protect the binding. However, the MSK is disclosed to the NAS, which can typically attack cryptographic binding if it terminates the tunnel at the NAS instead of the EAP server. This attack was not in scope for existing threat models for cryptographic binding because one NAS impersonating another is considered out of scope. Thus, existing cryptographic binding does not typically provide mutual authentication required for channel binding. I've added a new section 9.3: 9.3. Bid-Down Attacks EAP methods that add channel binding will typically negotiate its use. Even for entirely new EAP methods designed with channel binding from the first version, some deployments may not use it. It is desirable to protect against attacks on the negotiation of channel bindings. An attacker including the NAS SHOULD NOT be able to prevent a peer and server who support channel bindings from using it. Unfortunately existing EAP methods may make it difficult or impossible to protect against attacks on negotiation. For example, many EAP state machines will accept a success message at any point after key derivation to terminate authentication. EAP success methods are not integrity protected; an attacker who could insert a message can generate one. The NAS is always in a position to generate a success message. Common EAP servers take advantage of state machines accepting success messages even in cases where an EAP method might support a protected indication of success. It may be challenging to define channel binding support for existing EAP methods in a manner that permits peers to distinguish an old EAP server that sends a success indication and does not support channel binding from an attacker injecting a success indication. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] New draft on mutual crypto binding problem
Folks, I'd like to draw your attention to a draft we've put together describing the crypto binding interaction with channel binding and other peer-focused EAP services that I posted back in January. Please see draft-hartman-emu-mutual-crypto-bind-00.txt. there are a few rough edges. A couple of figures need to be added. we'd also like to describe where existing tunnel methods are in terms of vulnerability to these issues and where inner methods are in terms of providing keys and EMSKS. Dacheng zhang has compiled a lot of this data but I didn't get a chance to integrate it today. I'd like to thank all those who have helped with this so far and welcome any feedback. We'd like to request time at the EMU session to discuss this attack and the implications for our ongoing work. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding: EAP Success handling
Sam == Sam Hartman hartmans-i...@mit.edu writes: Sam Hi. Sam EAP has a complex history of success indications over the Sam years. Some methods have protected success indications; some Sam don't. Sam Especially as channel bindings are being initially deployed Sam it's going to be common to want to send channel bindings and Sam possibly fail if they do not match but not to require the Sam server to support them. So, bidding down attacks are a real Sam concern. Sam But there's another issue. Howe carefully does the client look Sam at this. From a state machine standpoint is' really important Sam that your client not just accept an eap success packet as Sam success if the method does have an internal success indication. Sam If a client does accept an eap success packet then a malicious Sam NAS could inject such a packet. Hi. As we're starting to gain implementation experience, it looks like this is a real problem with a lot of implementations out there. The server we're looking at just sends back an EAP success packet (unencrypted) as soon as it's sure that you've reached a success state. It's actually being a bit tricky to convince the server to send a channel binding reply. So, putting it mildly, I suspect a lot of clients will be fairly liberal in accepting unprotected success. This is kind of serious if you want to work with old servers, but it definitely is something we're going to want to document somewhere and discuss the implications. Obviously, we're going to want to define our standards-track tunnel method not to have these issues. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Channel Binding: EAP Success handling
Hi. EAP has a complex history of success indications over the years. Some methods have protected success indications; some don't. Especially as channel bindings are being initially deployed it's going to be common to want to send channel bindings and possibly fail if they do not match but not to require the server to support them. So, bidding down attacks are a real concern. First, if you are using an EAP method where success indications are not protected then you have a kind of hopeless situation. I'm not entirely sure how things are defined, but that might be incompatible with providing mutual authentication as a security claim. Channel bindings already does require mutual authentication out of the method. But there's another issue. Howe carefully does the client look at this. From a state machine standpoint is' really important that your client not just accept an eap success packet as success if the method does have an internal success indication. If a client does accept an eap success packet then a malicious NAS could inject such a packet. The value of the attack may be limited by a couple of factors: 1) The client may be expecting keying material. It's probably possible with some methods to get the client its keying material 2) If the NAS interrupts the conversation with the server, then it probably doesn't get its copy of the keying material. However form things that don't really use the keying material, this may be an issue. I think it's worth writing up a security consideration that clients implementing channel binding should be careful about their state machine in this regard. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-chbind-12.txt
The chairs asked me to prepare a new version with the following changes: 1) collapse the registrations in the lower layer type registry as requested by Sean. 2) Add a paragraph to the beginning of Appendix A. I believe I've made these changes. If folks are happy with these two minor changes I think we're ready to send this to the IESG. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Appendices in draft-ietf-emu-chbind-11
Joe == Joe Salowey jsalo...@cisco.com writes: Joe I think the following appendices of the channel binding Joe document are no longer supported by the rest of the text and Joe defined attributes. I think they are out of date and should be Joe removed: A.3. Downgrading attacks A.4. Bogus Beacons in IEEE Joe 802.11r A.5. Forcing false authorization in IEEE 802.11i I don't have an objection to removing these sections, although I actually think the attacks described are still real attacks. I think an alternate solution would be to add a paragraph to the top of appendix A pointing out that channel bindings are part of the solution. To actually prevent the attacks we'd need to define lower-layer documents describing what attributes you bind and you'd need to deploy with the appropriate configuration in the local database. I.E. as far as this document goes it does still support solving these attacks. We just reduced our scope to avoid the lower-layer specific issues, so more work is needed. I'd prefer to simply add a paragraph to the introduction of the appendix clearly explaining what additional work needs to happen. However I'm happy removing if that's what the WG wants. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Numbering of EAP Lower Layers Registry
Sean == Sean Turner turn...@ieca.com writes: Sean Sam, Is there a reason that the registry values aren't 1-9? I Sean know there were other values there originally and they were Sean dropped, just curious why they weren't renumbered. First, sorry for coming so late to the meeting. That was not some passive-agressive thing or the like, I just was sure that EMU was this afternoon at 1300. So I'm sorry I was not there for the discussion of the document I'm editing. I didn't renumber because I was concerned people might already be using these values. However, as it turns out, we haven't actually allocated the RADIUS AVP, so there's no way people can be using this already. I'm happy to renumber the registrations if people like. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Where I think we are after the channel binding last call
Hi. Here are my notes as editor on where I think things stand: 1) waiting for chairs to confirm that we have WG consensus to address Alan's comments in the way we did 2) Waiting for the chairs to judge consensus or lead a discussion on the contents of the EAP lower layers table. We should specifically resolve the question of whether preauth should be distinguished from non-preauth. 3) Unless someone objects we should pull in the ERP text. 4) Chairs to judge overall consensus on the document. I'd be happy to submit a version next week with the ERP text and if we can get there the new lower layer table. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Jim == Jim Schaad i...@augustcellars.com writes: Responding only to things I can respond to without reading the document. I''m in the middle of another document. I'll get to the rest sometime next week. Jim * In section 5.1 (para 3) - The following sentence does not Jim make sense to me. Message i2 is the information the AAA server Jim receives from the last hop in the AAA proxy chain which is not Jim necessarily the authenticator. Jim Specifically I do not follow the last clause and what it is Jim referring to. Are you stating that the element in the AAA Jim proxy chain may not be the authenticator? Yes. Jim If so, I would omit Jim the clause as it seems obvious to me since you are talking Jim about a chain. I'd appreciate comments from others. Jim * How does authenticated vs non-authenticated information get Jim denoted in a AAA message? It doesn't. All information in an AAA message is integrity-protected hop-by-hop. How much you trust it is up to your local policy. Jim * It is not clear to me if the EAP server is to reflect the Jim values from the EAP client in the response message or if it Jim should reflect values from the NAS/AAA path. EAP client. Jim * Is it reasonable/possible that a policy would pull some Jim attribute from the AAA path that is not supplied by the EAP Jim client and therefore need to reflect it to the EAP client as Jim part of the response? Or is the set of values to be reflected Jim back to the EAP client restricted by the set of values that it Jim supplies? In this version of the spec it's restricted to thes included by the EAP peer. I think we may need to relax that in the future, but there is significant complexity surrounding some issues there. So, clients MUST ignore unknown attributes but right now we don't send them. Jim * Section 7.2 - I am afraid I don't understand what this new Jim RADIUS attribute is supposed to be carrying. It describes the protocol between the peer and the NAS. It's sent in the channel binding and potentially over the AAA path. I think the name is correct: RFC 3748 (EAP) does call that a lower layer. Jim * Section 8 - You are talking about this information as being Jim validated by the AAA server as oppose to being validated for Jim consistency against the i1 data by the EAP server. Is this Jim what you are really intended? I'm not intending to make that distinction in section 8. No, we're talking about the same validation as in section 5. I think this may be terminology rot; will check when I reconcile your comments against the document. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
I'll respond to the question of channel binding support now. I think the current text permits an EAP method to not send channel binding if it knows the server fails to support it. If your method can discover that and optimistically avoid sending channel binding that's fine. I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Jim == Jim Schaad i...@augustcellars.com writes: Jim I want to make sure that we have distinguished between the two Jim statements 1. The server says that I don't support these Jim specific attributes Jim and 2. The server does not tell me that it Jim did or did not do matching of some attributes. Jim The first I think is totally optional, but the second is Jim necessary for the tunnel draft and should be made explicit in Jim this draft as something that needs to be done. I think section 5.3 clearly requires that a peer learn whether the server did do matching and if so, what attributes it successfully matched. We don't currently have a way for the server to say these attributes didn't match. That's kind of tricky and I'd prefer that to be a future work item. I've left extensibility for it. Also, the client's request to the server is integrity protected. I believe we should require and would appreciate you checking that we do require: 1) A client supporting channel binding to a server supporting channel binding will get channel binding. An attacker cannot downgrade to no channel binding. I believe that by doing channel binding over an integrity-protected channel we get that. 2) If you do channel binding the client will learn the result and will learn which attributes it sent were considered and met whatever consistency check the server did. This is a little vaguely worded because there's a lot of latitude for server policy. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Yoshihiro == Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp writes: Yoshihiro Hi Sam, Since authorization and accounting with the use Yoshihiro of the pre-authentication may be different from those Yoshihiro with the use of normal authentication, it would be good Yoshihiro to differentiate pre-auth and without pre-auth for Yoshihiro network access authentication protocols that support Yoshihiro pre-authentication, PANA and 802.11 are such protocols as Yoshihiro far as I know. OK, but Dan is arguing to remove them. Yoshihiro BTW, I also commented about adding IEEE 802.16m and IEEE Yoshihiro 802.21a for EAP lower-layers. Here is the references for Yoshihiro them: Right. I didn't feel qualified to evaluate these. Ultimately the chairs are going to have to decide what the table entries are; I think that's beyond what I can do as an editor. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Hao == Hao Zhou hz...@cisco.com writes: Hao Rereading the updated chbind draft, it has already defined the Hao mechanism for two way communication and tunnel EAP draft just Hao defined a TLV container to carry the Channel binding data Hao defined in Section 5.3, so we should be ok. No change is Hao needed on the tunnel EAP draft on this, other maybe called out Hao Section 5.3. And to indicate it's two-way. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Yoshihiro == Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp writes: Yoshihiro Hi Sam, Yoshihiro (2011/10/20 21:48), Sam Hartman wrote: Yoshihiro == Yoshihiro Ohbayoshihiro.o...@toshiba.co.jp writes: Yoshihiro Hi Sam, Since authorization and accounting with the use Yoshihiro of the pre-authentication may be different from those Yoshihiro with the use of normal authentication, it would be good Yoshihiro to differentiate pre-auth and without pre-auth for Yoshihiro network access authentication protocols that support Yoshihiro pre-authentication, PANA and 802.11 are such protocols as Yoshihiro far as I know. OK, but Dan is arguing to remove them. Yoshihiro I see. As long as all lower-layers are treated in a Yoshihiro consistent manner, I am ok. Maybe it is cleaner to Yoshihiro define pre-auth information as separate channel binding Yoshihiro data. You might not want to do it that way. It seems that learning the eap-lower-layer from the NAS may influence your accounting handling (especially for pre-auth) even if the client does not specify channel binding. That's something for the WG to consider and possibly something where we need to circle back with radext. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Submitted 10
Glen == Glen Zorn glenz...@gmail.com writes: Glen On 10/20/2011 3:09 AM, Sam Hartman wrote: I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Glen Great, so what are we supposed to do now? WGLC was issued on Glen draft-ietf-emu-chbind-09. The last call is not complete. Glen Shall we just start over? Documents are updated to reflect feedback during last calls all the time. It happens in WGs I chair; it happened with documents for which I was the AD; I've been asked to do it by ADs and other chairs. Obviously, sometimes it is done wrong. My thinking is that Alan's comments had been outstanding for a while, seemed fairly obvious and with the exception of the question about encoding of responses were non-contraversial. None of them seemed to require a second last call. By submitting 10 I've made a version with the changes folded in available for review. What I did is clearly permitted by the process. The chairs may of course decide I made an error and that one of Alan's comments didn't have sufficient consus. They can ask me to (or do it themselves) resubmit 09 as 11, ask me to remove some text, or give more specific guidance. We may also discover that I incorrectly applied Alan's comment. You still had the options you had before. You can review 09 if you like and send comments on 09. You can reply to Alan's comments and respond to them. You have some additional options now. If you haven't started reviewing yet you can start with 10. If you'd like you can review the diff between 10 and 9. You can review 9 and 10 separately if you have a lot of free time on your hands. You can ignore the whole thing. You get a chance to see Alan's context in the text. You can better appreciate them and if you find a problem bring it up. If you have trouble finding 09 or a diff between 09 and 10 let me know; I bet we can find one if we work together. If you have an objection to text in 9, text in 10, changes between the two bring it up. Objections of this form without an objection to actual text are not constructive. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Yoshihiro == Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp writes: Yoshihiro Hi Sam, Please see my comments below. Yoshihiro sense. Sending channel bindings in the secure Yoshihiro association protocol can work even with ERP [RFC5296] in Yoshihiro which previously established EAP key material is used for Yoshihiro the secure association protocol without carrying out any Yoshihiro EAP method during re-authentication. I like this text. Objections to including it? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). Rafa Sending its identity does not mean that it must be carried in Rafa the EAP response/identity. In fact what I suggested is to Rafa carry the identity in the first message but not contained in Rafa the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. Rafa Basically EAP is a lock-step protocol where it is required to Rafa get a request to obtain a response (in the peer side)). So the Rafa EAP peer state machine implementing the EAP standard protocol Rafa will react after receiving an EAP request. So I see two Rafa options: either you hack the EAP peer state machine to return Rafa an EAP response/identity without receiving any EAP Rafa request/identity (this violates the standard and so we need Rafa to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Rafa or directly at GSS-API Rafa level you create a EAP response/identity and include the Rafa identity (which seems weird taking into account that we have Rafa an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. Rafa Personally, I do not like either (considering the standard RFC Rafa 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Hi. I've added PANA (pre-authentication). I wonder about the whole lower layer table. Why is it important to distinguish PANA with pre-auth from pana without pre-auth? Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with pre-auth? I'd appreciate it if someone who cared about network access told me what to do here:-) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Submitted 10
I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Thanks Alan for the comments! --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on the eap-tunnel-method-00 draft
Jim == Jim Schaad i...@augustcellars.com writes: Section 4.2.10 - How can I know if the server does or does not process the channel binding TLV? This may be part of my policy as a peer depending on circumstances. [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require acknowledgement, and is designed to be only one way, for client to send some channel binding data to the server for verification purpose. There is no feedback provided. The indication of whether the server supports channel- binding and/or validated the channel-binding could be conveyed in other TLVs to be added, if the WG agrees to be valuable. JimSam - do you see this as being an issue for abfab? It's an issue for EMU actually. See Section 5.3 of draft-ietf-emu-chbind. Channel binding must be two-way and must follow the semantics of that section. And yes, draft-ietf-abfab-gss-eap depends on those semantics. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] GSS-EAP: do we ned an identity request
[EMU copied for EAP input] Here in ABFAB, we're designing a new EAP lower layer for applications to use for authentication. We're using the GSS-API (RFC 2743) as our application integration point. Currently, our lower layer is kind of chatty. The peer sends a first message that roughly says Hi, I'd like to authenticate. Then the authenticator sends an identity request EAP message. Then the peer sends an identity response. Then the authenticator (probably after an AAA interaction) respons with the first EAP method message. As best we can tell that round trip is unneeded. We could instead include an unsolicited identity response in our first message from the peer to authenticator and get a request with an EAP method message from the first message from the authenticator. We can't see any down side of this. There seems to be nothing in the identity request. We already have another approach for network selection. If you want to know who your authenticator is in order to decide on an identity, we have a lower-layer specific mechanism for that. I'd appreciate any comments. From ABFAB participants, do we want to make this optimization? From EMU participants are we missing anything? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
Yoshihiro == Yoshihiro Ohba yoshihiro.o...@toshiba.co.jp writes: Yoshihiro [1] As far as I understand, the method-based channel Yoshihiro binding is not applicable to ERP. For completeness of Yoshihiro the specification it may be good to add some text to Yoshihiro clarify this. I'd welcome suggestions. I'm not really familiar with ERP. Yoshihiro [3] Probably this was discussed in the WG, but I want to Yoshihiro understand the motivation for the namespace in Channel Yoshihiro Binding Encoding because it seems to be a hard Yoshihiro requirement if the peer has to know what namespace (or Yoshihiro protocol) is being used between an EAP authenticator and Yoshihiro EAP server. Also, in some case, the channel binding Yoshihiro operation may be performed with a standalone Yoshihiro authenticator since, due to EAP's mode independence Yoshihiro property, the peer does not know whether the Yoshihiro authenticator it is talking to is a pass-through Yoshihiro authenticator or a stand-alone one. What namespace Yoshihiro should be used with a standalone authenticator? The namespace ID simply names where the attribute comes from. If you are describing some value that is available in a RADIUS ID, then you should use the RADIUS namespace. The EAP server (which as you point out may be the authenticator) is responsible for matching up that information in whatever form it has it. For attributes available both in the diameter and RADIUS namespaces I'd expect some lower layer document to describe which one to use regardless of whether an AAA protocol is in use or which one is in use. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09
Alan == Alan DeKok al...@deployingradius.com writes: Alan For me, echoing a copy of an attribute (value and all) means Alan that the server validated the attribute. Echoing nothing Alan means that the server doesn't know what to do with the Alan attribute. Echoing an attribute with an empty value Alan means... what? It means the server validated the attribute. I think there are several important reasons not to echo the value in the attribute. 1) Space. Some EAP methods limit the channel binding space. For all EAP methods there is value in minimizing the size of messages. 2) What does the peer do with the echoed value? What if the echoed value is different from what the peer sent? MAY the peer fail in that case? SHOULD the peer fail in that case? MUST the peer fail in that case? Why do we want to introduce complexity here? The peer clearly needs to know what attributes the server validated. I don't understand why the peer needs a copy of the attribute value it already sent except that it's convenient if you're using an existing RADIUS library. Hmm. OK, I thought there were some fairly compelling use cases related to extensibility. I was thinking for example we might provide a way to indicate why a EAP server failed to validate an attribute. For example, in a channel binding failure we might decide that we want to indicate which attributes validated and which ones did not and we might want to use the value for that. However, unmodified clients might misinterpret that, so this extensibility option isn't nearly as valuable as I thought. We can always invent a new namespace as an extensibility mechanism if we need it. So, we're left with space as the main argument and I agree it's not compelling. I propose that: 1) We send full values in responses 2) Peers MUST ignore differences between the value sent in the channel binding data and channel binding response. This gives us the option of changing the value if we ever find a reason to do so. It also prohibits some particularly bad peer implementation strategies like doing a binary comparison of the channel bindigns sent against the response. 3) Codes should define what attributes you include. For success we include attributes the server considered in making the decision that channel binding was successful. For our current failure code I think we should also include all the attributes the server looked at--we are not indicating what attributes are wrong. My rationale is that it may not be easy to tell what's wrong; it may be that some attributes are inconsistent and either of them alone could have been OK, but both together was not. 4) Indicate that if a client doesn't understand a code, it treats it as failure. Would this work? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [abfab] GSS-EAP: do we ned an identity request
Rafa == Rafa Marin Lopez r...@um.es writes: Rafa Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). Rafa Sending its identity does not mean that it must be carried in Rafa the EAP response/identity. In fact what I suggested is to Rafa carry the identity in the first message but not contained in Rafa the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. However it's certainly easy enough to carry it elsewhere. So, if there is a reason to do so I'm happy to invent our own subtoken for it. do you support the general concept of an optimization here? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09
I'm happy to make changes regarding your comments; a couple of them were not directly actionable but I can make best guesses. Most of them were directly actionable and I agree the changes improve the text. I'd appreciate comments from the groups on whether we start codes at 2 or 1. My default will be 1 unless a couple of other people come forward and ask for 2. I do disagree with a couple of comments however; see below. Alan == Alan DeKok al...@deployingradius.com writes: Alan Continuing from the previous message... It says: Alan A related question is should we allocate a code for Alan Diameter? :) Exactly when someone plans to use it and works through the details. I would object to that allocation now. Alan 5.3.3. Radius Namespace Alan I suggest leaving out all re-definition of RADIUS AVPs. Alan Instead, refer to RFC 2865 Section 5. Say that the Alan NS-Specific data is RADIUS attributes, in the RADIUS attribute Alan format. But the RADIUS packet header (code, length, Alan authenticator) is not included. I'd prefer to keep the definition in. Alan It also says: AlanRADIUS AVPs are encoded with a one-octet attribute type Alan followed by a one-octet length followed by the value of the Alan RADIUS attribute being encoded. The length includes the type Alan and length octets; the minimum legal length is 2 for an Alan attribute with no value. Alan This last bit is not true. RFC 2865 forbids attributes with Alan Length of two. Instead, the entire attribute is suppressed, Alan and never placed into a packet. Alan The same should apply here. Unfortunately, as discussed in the text, we need to be able to send empty attributes in channel binding response. I understand RADIUS has no meaning for empty attributes, but I think we have a justified meaning for expressing that. I think the text is correct as is. Alan It says: AlanSome RADIUS container specifications forbid sending Alan attributes with no value. Alan No, the base RADIUS protocol forbids sending attributes with Alan no value. It is not clear what they mean, or how it is better Alan to send them than to send nothing at all. AlanThis prohibition not withstanding, these attributes SHOULD Alan be sent with no value in channel binding responses. Alan I am not clear why the document makes that suggestion. If Alan it's a SHOULD, there should be explanation as to why it's a Alan good idea. It's a SHOULD because we may specify cases where you include value or where you don't fully understand the container format. The definition of channel binding responses indicates that by default you SHOULD send the attribute without a value and explains why. (You don't want to echo back all that data.) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Channel Bindings: Ready for Last Call?
Hi. I've just submitted a draft that I think is ready for last call. Changes include: * Figures, thanks Katrin ! * Text stolen from Bernard's draft for the eap lower layer attribute * IANA considerations for the eap lower layer attribute * Removal of the 802.11-specific text per WG discussion in Quebec I'd appreciate it if someone besides Katrin would confirm that the diagrams match the text. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan: 1) My desire to use GPSK with anonymous server authentication is more or less unrelated to any other part of this discussion. I want to be able to do it because I think I might deploy it and I don't want the spec to forbid a deployment I consider reasonable. There is no security justification for forbidding GPSK with strong keys combined with anonymous authentication. Again I'd be happy to provide text. 2) You've convinced me that GPSK is not a good MTI choice because of the dictionary attack resistance issue. I didn't carefully consider before suggesting GPSK as an MTI mechanism. I do think GPSK should be permitted to use (point 1) but I agree that's a kind of obscure deployment. 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. 4) I don't think we have any generally appropriate MTI mechanisms here, so we should not choose one. I think it would be fine to say implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of their choice. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan == Dan Harkins dhark...@lounge.org writes: Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan == Dan Harkins dhark...@lounge.org writes: Dan On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: Dan == Dan Harkins dhark...@lounge.org writes: Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. EAP-GPSK is not resistant to dictionary attack and therefore would Dan be unqualifed to be used according to the changes I propose Dan that you already support (i.e. that the EAP method be resistant Dan to dictionary attack). OK. Then I think we need to broaden up your text somewhat. I think GPSK is fine in a deployment where you expect random keys. I think something that has offline dictionary attack resistance would be fine in an area where passwords might be used. I'd like to relax your text to permit both. Dan Regarding what it means to be resistant to a dictionary Dan attack, let me quote some experts in the field [1], One sees Dan whether or not one has security against dictionary attacks by Dan looking to see if maximal adversarial advantage grows primarily Dan with the ratio of interaction to the size of the password Dan space. I think that definition is OK. I don't want us to require ZKPP to get the dictionary attack resistance security claim. I agree GPSK should not have the dictionary attack resistance security claim. I do want GPSK to be permitted in environments where it is appropriate. I absolutely do not support EAP-PWD as a MTI for this document unless EAP-PWD is moved to the standards track. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Agenda items IETF Meeting 81
I'm not actually sure channel bindisgs will need time this round. I think I've done exactly what I said I'd do on the list. I think one get the diagrams and a review or lack of review on the 802.11 information, we should be ready for last call. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Some questions about eap type code and the tunnel method
I'd like to confirm my understanding. The current text proposes the use of eap type code 43. I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. Does the current text mandate support for eap-fast v1 as well as v2? Is it expected that most implementations will support v1 and v2? Is it desired that people be able to create a v2 only implementation? I think based on answers to these questions I at least will be able to better determine my opinion on the type code issue. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
Based on the answers to my questions, I strongly support allocation of a new EAP type code . I think using the existing type code will significantly disadvantage implementations that want to implement the IETF spec but not eap-fast v1. I believe that is highly undesirable. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
Alan == Alan DeKok al...@deployingradius.com writes: Alan Glen Zorn wrote: There seem to be two issues here: renaming the draft allocating a new EAP type. For which one are opinions being solicited? Alan Allocating a new EAP type. My opinion is that we have two options: 1) Allocate a new method type now. 2) Revisit this issue at the end. I don't think we'll be in a position to decide for sure we can keep the method type until we reach WGLC. However we can always short-circuit the issue early. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Alan == Alan DeKok al...@deployingradius.com writes: Alan Stefan Winter wrote: Attribute parsing should be easier with this option 1 - Length can always serve as a pointer to the next attribute, with explicit namespace ID. With option 2, attribute delimiters are only within NS-Specific, and Length points to the Namespace, if any. That makes two code paths, one for parsing NSID delimiters, and one for parsing attributes. Alan My $0.02 is that it's easier to do: Alan Parse NS stuff NS1 - parse protocol-specific 1 NS2 - parse Alan protocol-specific 2 I think this is true on the server. However, I'd really appreciate your thoughts on what will happen inside the EAP peer itself? My assumption is that outside of the guts of a TTLS implementation, EAP peers today don't have knowledge either of RADIUS or DIAMETER. So, a format that minimizes how much they need to understand either of these protocols would be valuable. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Consensus Call
Alan == Alan DeKok al...@deployingradius.com writes: Alan There is plenty of BSD-licensed code available for packing Alan and unpacking RADIUS attributes. There should be little cost Alan to re-using that, and a larger cost in writing a new attribute Alan packer. Assuming RADIUS is basically the only namespace we end up needing this probably is true. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Consensus call on EAP Tunneled method
Glen == Glen Zorn g...@net-zen.net writes: Glen On 4/16/2011 2:21 AM, Stephen Hanna wrote: I agree with Katrin's count for the email poll. When combined with the count from the meeting in Prague (since Alan asked for only folks who didn't attend the EMU WG meeting in Prague), Glen Based upon a policy that was AFAICT created out of thin air by Glen Bernard, who has AFAICT zero official status in emu (but, Glen OTOH, _has_ evinced the ability to count). Glen, your message lacks a certain clarity, which is to say I can't really understand what it means. However, I've thrown darts randomly around the room, and managed to find most of them where they landed, and based on that, I think you might be saying the following: Bernard came up with the idea that the chairs should have a consensus call in the meeting and ask for input from those not participating in the meeting on the list. You think this comes from thin air. If that was not roughly what you were trying to say, stop here and see if you can recommend a translator I can use:-) If that was what you were trying to say, take a look at RFc 2418, the BCP on working group procedures. That document requires that the sense of the room and the list together be taken into account: decisions are made on the list but the people in the room count there. Also, RFC 2418's language encourages something very like what the chairs did. In addition, this particular part of IETF process has made its way all the way to an IAB appeal as part of evaluating the decision te deprecate site-local addresses in IPv6. The appeal response specifically cited the v6 chairs's decision to handle the list traffic in a manner very similar to what the EMU chairs did here--and yes, this was cited as a *good thing* in following our process. So, while the counting may be lacking, the process grounding at least to the extent I'm discussing it here seems quite firm. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Really no proposals submitted so far?
I just want to confirm I haven't missed mail. It's my understanding that the call for proposals for tunnel methods closes March 7 and that so far we've seen no submissions. Is that correct? ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Call for agenda items for IETF
I'd very much like to discuss the changes to the channel binding draft. The highest level item is whether we're going in the right direction. I'd also like to come to closure on Alan's comment about whether we want each AVP split out or whether we want to reuse more of the RADIUS/whatever encoding and have one blob per namespace. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Bindings: RADIUS or Diameter namespace
I considered retaining namespace-specific packing. my concern is that in the channel binding response you want to remove values. This ends up being a bit namespace specific because of VSAs but seems to argue for the channel binding logic ending up getting stuck with a fair bit of namespace specific logic. I also really wanted to avoid more than one length for a given attribute because that tends to cause problems in a security protocol--they can get out of sync. A blob of RADIUS stuff all with its own length would not suffer from the length issue so much. This is an area where I want us to decide quite quickly what the answer is going to be, but where I don't have a hugely strong opinion on what it is. I threw something out to make forward progress. So long as we can actually decide on something soon, I'm happy to change to another way of encoding. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-chbind-05
Joe == Joe Salowey jsalo...@cisco.com writes: As I discussed with the chairs, I'm making an update, but it's more of an update to address specific detailed comments than to really move the document forward. There have been some issues in my availability, which I believe are very close to being resolved. This work is a dependency for draft-ietf-abfab-gss-eap, which is one of my major projects so I definitely do have the interest to move it forward. I'm sorry that did not happen as much as we'd all like this cycle. Joe - Protocol definition - there is general consensus that we Joe should include the protocol definition within this document. I Joe think it would be good to flesh out the following approach in Joe the document to see if it meets working group expectations: Joe define a Channel-Binding-TLV to hold channel binding data; Joe define channel binding data as diameter AVPs. The protocol Joe should define attributes for at least one case (probably Joe 802.11) and provide guidance for creating binds for other Joe EAP/AAA usages in other follow-on documents. Agreed. Very little happened here. Joe Detailed comments follow: Joe 1. Introduction Joe I think it would be good discuss that the problem is manifested Joe when the same set of credentials are used to access different Joe classes or types of services. This is discussed later in Joe section 4.3, but I believe this to be fundamental to channel Joe binding problem and should be discussed in the introduction. Joe When the EAP server is centralized and accessed from different Joe for different services it typically uses the same set of Joe credentials to authenticate itself to the peer for each service Joe so the peer cannot differentiate between services. The server Joe could also attempt to detect any discrepancy by forcing the Joe client to use different credentials for each services. Using Joe different credentials for each different class or type of Joe service has numerous problems. I added a brief mention in the introduction. Let me know if more is needed. Joe 2. Section 3 Joe In the Enterprise network case its not clear to me that channel Joe bindings alone can alleviate this attack. The peer does not Joe know which VLAN its traffic is going to, it just knows the Joe SSID. Likewise the AAA server does not know what VLAN the Joe authenticator is switching the peers traffic to, it only knows Joe what it told the authenticator to do, if the authenticator is Joe compromised, it need not comply. It is possible that this may Joe be detected by another part of the infrastructure, but this Joe would involve more than the authenticator, peer and AAA. The unstated assumption here is that the authenticator was only trusted to attach to one of the networks. I.E. separate physical infrastructure for enforcing separate security policy. That's been stated. It does diminish the applicability of the use case. I also added the abfab use case; since that's been chartered it's reasonable to mention here. Joe One mechanism that deployment use to avoid the enterprise and Joe provider problem today is to use different credentials for Joe remote access versus enterprise access. This is often not Joe ideal, but it addresses the problem. mentioned. Joe 3. Section 4 Joe It could be possible to use EAP channel bindings to address Joe some more traditional channel bindings uses cases by carrying Joe information from the lower layer or encapsulating tunnel in the Joe transported method. Mentioned. I dread writing or reading The use of EAP Channel Bindings to Provide RFC 5056 Channel Binding for EAP (draft-something-eap-chbind-for-chbind-for-eap) I think it's an illustrative example of the difference, but at this time I definitely don't want to get into whether it's a good idea. For your information, I considered and rejected using EAP channel binding for RFC 2743 channel binding (GSS) in draft-ietf-abfab-gss-eap. Using the MSK and an exchange between the peer and authenticator was simpler and didn't depend on the server verifying I1 against I2 for that particular attribute. ABFAB still depends on EAP channel binding in a number of other respects though. Joe 4. Section 4.2 Joe This section states that for the system to function the EAP Joe server has to have access to a local database. THis doesn't Joe sound right to me. I wouldn't expect many systems would be Joe designed this way. The accuracy of the AAA attributes would be Joe verified by the AAA server that hosts the EAP server, but Joe perhaps this is too fine a distinction for this document. I Joe would expect any processing of AAA attributes to be done in the Joe AAA server. I have added text to loosen the architecture in this regard. However, it is very messy if your AAA
Re: [Emu] How does cryptographic binding work
Alan == Alan DeKok al...@deployingradius.com writes: Alan Sam Hartman wrote: * The client wants assurance that it's talking to a consistent server so that you only end up having to authenticate the server at one level. Alan I have always been unsure as to why clients don't tie Alan credentials to a server certificate. Instead, they are Alan usually tied to an SSID. And while clients can verify the Alan servers CA, the CA is usually in a global CA store. Hmm. Android at least seems to let me pick an expected CA for each SSID separately. I don't have EAP here at home so I've not played with the security. That presumably means that wpa_supplicant gives you enough rope under the covers. I can't help the Windows and mac users:-) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] How does cryptographic binding work
Joe == Joe Salowey jsalo...@cisco.com writes: Joe The basic reason for this is that EAP methods have a well Joe defined mechanism to output key material. There hasn't been a Joe mechanism to import data into a method, channel bindings may Joe change this. OK, but I'm not sure this quite gets you the properties you want. As best I can tell: * The server wants assurance that if an inner method is somehow lifted out of a tunneled exchange, the inner method cannot be used alone or in a different tunnel. * The client wants assurance that it's talking to a consistent server so that you only end up having to authenticate the server at one level. Impersonating peers to servers and impersonating servers to peers both have value to an attacker in different situations. I think these are the properties you want (And I think the definition in RFC 3748 is a bit under specified) and I'm not sure how what you've described gets that. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] make EAP Method Support for Transporting AAA Payloads WG item
Alan == Alan DeKok al...@deployingradius.com writes: Alan Hoeper Katrin-QWKN37 wrote: I did not attend the last EMU WG meeting in person, but as a remote participant it appeared to me that there was a general consensus that the channel binding draft (draft-ietf-emu-chbind-05) should reference âEAP Method Support for Transporting AAA Payloadsâ (http://tools.ietf.org/id/draft-clancy-emu-aaapay-04.txt) as solution for transporting channel binding information. Alan We need to confirm on the list (a) what we propose, and (b) Alan whether or not it has consensus. In that case, shouldnât we make this draft a working group item? Right now it is still a personal draft. Alan Sam's suggestion (IIRC) was to merge the two documents. The Alan channel binding document is small, and may be better served by Alan specifying the protocol, too. Correct. I was planning on taking text from the individual document, and explicitly referencing that in acknowledgements. If there are significant authors of clancy-emu-aaapay who are not already authors of emu-chbind, we can create a contributors section to acknowledge their significant text contributions. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen == Glen Zorn g...@net-zen.net writes: Glen Or we could use the more direct much simpler approach of Glen allowing the client to authenticate the network to which it is Glen attached use that data to decide by itself. This can be Glen done today using EAP-TTLS. How? I'd appreciate an answer in approximately similar level of detail as I have given you the answer on the channel binding approach. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding: transitive trust
Glen == Glen Zorn g...@net-zen.net writes: the corporate network example from my first message as a case in point. The corporation has two levels of trust: internal and everyone else. Internal entities may claim to be corporate access points. People who are part of everyone else, are not permitted to make this statement. The corporation need not worry about what happens if a roaming partner claimed in AAA attributes to be the corporation's network: such a statement would simply be rejected by some proxy within the corporate border. Glen s/within/at: if said proxy is even one AAA hop inside the Glen border an invalid claim may be indistinguishable from a valid Glen one. The key word there is may. Depending on topology, configuration and policy, it may be possible to distinguish things beyond the border. I agree the border is a logical place to make this distinction though. More general, at each level in a proxy chain, you can consider whether the party you receive a message from is permitted to claim the attributes that are claimed in the proxy request. Glen You can. but in this context it's difficult to see how an Glen intermediate proxy could filter on SSID (for example) w/o Glen detailed knowledge of the topology of both the originating and I absolutely agree that the intermediate proxy needs sufficient knowledge to perform the filtering. Depending on the specific filter, it is definitely the case that the proxy will need information about the origin and destination organizations and networks. That level of detail is very often spelled out in business agreements for trading partners, in the banking industry, and presumably in other industries I'm less familiar with. I'm not aware of cases where AAA configuration was the subject of these agreements, but I've also not been in a position where I cared about the AAA infrastructure before. But yes, for a lot of filters you need to understand the routing topology well enough to understand whether a particular proxy should legitimately be on the path between you and a given origin. For RADIUS at least, I do understand the difficulty in getting that information; I'd rate it as higher than you'd probably want for most current network access situations, but definitely not impossible. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding: tunneled methods
Glen asked me to explain my tunnel related comments more. It would be desirable to reduce the number of methods we need to add channel binding to. For example if eap-ttls supports channel binding [1] and I'm running some other method inside it, then I may not care whether that method supports channel binding. Similarly, if I wish I had channel binding in some method that does not have channel binding, I can always tunnel it. [1] I think it does, but I'm not sure it is in alignment with draft-ietf-emu-chbind at the moment. This seems like such a good idea we wrote it into the charter. Unfortunately, it's never that simple. Channel binding data is a statement from the client to the EAP server about the client's understanding of the entity the client is authenticating to/the environment that the client is gaining access to. the EAP server's job is to verify that the channel binding is consistent and if not, reject the access request. This model depends on the server being able to confirm that the channel binding statements are actually from the client. Clearly, if an attacker could change channel binding, then the system will not work. However, typically tunnel methods authenticate the server to the client but depend on the inner method to authenticate the client to the server. Let me give a concrete attack. Consider an EAP server that takes the channel binding data from the outer method if present otherwise the inner method. A client intends to use GPSK and includes channel binding data there. An attacker acts as a man-in-the-middle, receives the GPSK lower layer messages and replaces them with lower layer messages tunneling GPSK in TTLS. So, the TTLS tunnel runs from the attacker to the EAP server, while the inner GPSK runs from the client to the EAP server. If this is starting to look a lot like the standard set of EAP tunnel attacks, you're absolutely right. The attacker inserts channel binding data in the outer tunnel and thus replaces the channel binding. This is not a practical attack. I'm not sure there are particularly practical attacks in this space. However, I think we have an obligation to specify constraints such that the system is secure. Here are examples of constraints that would be sufficient. * Cryptographic binding is used to prove that the outer tunnel party knows the inner tunnel key. Note that proving that the inner tunnel party knows the outer key would not generally be sufficient mostly because a lot of the inner methods you might want won't ever support this. * Never except the same equivalence class of EAP methods both inside an outside a tunnel. That is, in a given configuration require that if GPSK is to be used it either always appears in a given tunnel for a specific user or never does. I say equivalence class because it's possible that an attacker might be able to transform the messages of one method into another. For example I'm not sure whether an attacker can turn one of the TLS-related methods into another. * Assuming that adding channel binding information can never make a request that would fail succeed, take channel binding attributes from the inner method first. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] [Sam Hartman] Re: Channel Binding Discussion at IETF 77: why bother
This time from the right address. ---BeginMessage--- Glen == Glen Zorn g...@net-zen.net writes: Hi. I have read the later messages on this thread, but it sounded like you and Alan were talking past each other a bit, so I want to come back to where I think the disagreement is introduced. Glen Sam Hartman [mailto://hartmans-i...@mit.edu] writes: Consider a corporation that has an internal network and that also has agreements with WIFI hotspots to provide its employees connectivity. Policy requires that people use a different set of firewall rules and VPN configuration when connecting at the WIFI hotspots than when connecting to the home network. Typically clients determine which network is in use by the SSID. They use the same EAP credentials in both cases. You can imagine that the corporation would know the identities of its own access points. In particular, a combination of configuration on the AAA servers and at the boundary firewall could mean that the AAA servers know whether a given request for access is coming from the corporate network or a WIFI hotspot. Today, however, the corporate AAA infrastructure does not know what the client thinks it is connecting to. If the client disclosed the SSID it sees then the corporation would be in a position to enforce the security policy. Glen agreed that channel binding could address this. Glen Indeed it could, but all you really seem to be asking for is a Glen way for the corporation to be able to control the Glen configuration of the client. As you point out, it is Glen reasonable to expect that the corporation knows the identity Glen of its own access points; why does it matter what the client Glen _thinks_ (for lack of a better word) that it is attached to? Glen I cannot see any purpose for the client sending the SSID of Glen the network to which it attached. In fact, it seems that all Glen that is necessary is the ability to remotely modify the Glen configuration of a client; why is the job of EAP, again? The client has two different policies both of which have been configured by the corporate infrastructure. The first policy is a policy to be used when connected directly to the corporate network. The second policy is a policy to be used when connected to more open networks. The client knows both policies. The client needs to choose which one to use. The client needs a procedure for connecting to the network such that on success: 1) The client uses the corporate policy on the corporate network and the other policy on other networks 2) The client has an authenticated EAP and 802.11I association; the EAP association to the EAP server and the 802.11I association to the access point 3) No attacker can convince the client to use the corporate policy when connecting to other networks or the other policy when connecting to the corporate network without the cooperation of the corporate AAA infrastructure So, somehow the client needs to discover which policy to use. We could use an insecure discovery mechanism and validate the results of that discovery with a secure protocol later. Alternatively we could use a secure discovery mechanism and bind the results of that mechanism to the rest of our protocol. As far as I can tell binding secure discovery to the later stages of the protocol is exactly as hard as validating insecure discovery, so I'll design a solution for insecure discovery. I propose that the client discover which policy to use by looking at the SSIDs advertised by the APs. I understand SSIDs may not be unique; as a consequence our client will end up being unable to connect to a non-corporate network that happens to have chosen the same SSID as the corporate network. If you design a better discovery mechanism we can remove this defect; in practice if the corporate SSID is well-chosen this is not a significant problem. So, based on the SSID, we have discovered what policy we will try to use. Since our discovery approach is entirely insecure, an attacker can give us the wrong policy to try. If our overall approach is secure, then we must fail at a later step if that happens. In this system, we've posited that the corporate AAA infrastructure knows whether a given AP is corporate or other. So, we want to take advantage of that information. We need to change the corporate AAA behavior to do that as it doesn't provide that service today. We could: 1) We can tell the corporate AAA infrastructure what policy we plan to use and have it validate that decision. 2) The corporate AAA infrastructure can tell us what policy we should be using. The channel binding approach is option 1. We tell the corporate infrastructure what policy we're using as a channel-binding attribute in the EAP exchange. If we indicate we're using the corporate policy on an other network, then the corporate AAA
Re: [Emu] Channel Binding Discussion at IETF 77
I will definitely have a revision for IETF 78. I may not have everything I'd like to have done ready for that revision. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Channel Binding Discussion at IETF 77
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that meeting, I sat down with Glen to understand his concerns with the document. I'd like to write up my notes on that meeting and to discuss what I think the critical next steps are for the document. I presented two motivating examples, one of which is I think directly within the previous discussions of channel binding and one of which is my motivation for caring about the problem. Consider a corporation that has an internal network and that also has agreements with WIFI hotspots to provide its employees connectivity. Policy requires that people use a different set of firewall rules and VPN configuration when connecting at the WIFI hotspots than when connecting to the home network. Typically clients determine which network is in use by the SSID. They use the same EAP credentials in both cases. You can imagine that the corporation would know the identities of its own access points. In particular, a combination of configuration on the AAA servers and at the boundary firewall could mean that the AAA servers know whether a given request for access is coming from the corporate network or a WIFI hotspot. Today, however, the corporate AAA infrastructure does not know what the client thinks it is connecting to. If the client disclosed the SSID it sees then the corporation would be in a position to enforce the security policy. Glen agreed that channel binding could address this. We'll come back to whether it's a good idea in a bit. My motivation is related to the technology being developed by the Moonshot project (http://www.project-moonshot.org ). We'd like to use EAP as part of application authentication. With network access, there are a lot of situations where one network is much the same as another. However with application authentication the party you're talking to matters a lot, especially in federations with relatively liberal membership policies. I might well be willing to send information to my company's ERP system that I should not send to a rogue machine at a competitor that is part of the same federation. I'd like to know the difference in who I'm talking to. Glen described several significant concerns about the way channel binding has been handled. First, there is the basic complexity concern. EAP has grown and evolved over the years, in many cases with design taking place after the fact. Adding a new facility has a high cost. However, there are some things in the current draft that make that cost even higher. I, and a few others have argued that all EAP methods should gain channel binding support. Glen points out that is a lot of work and argues it is unnecessary. Glen is also concerned that each EAP method will handle channel binding differently.His assumption is that each method would have a different set of channel binding attributes that it carried, a different mechanism for carrying them, and different names/numbers for the attributes. So, rather than just supporting channel binding in some deployment of EAP, you would need to tie it to a particular method or small set of methods. He acknowledged that we could have some standardized way of dealing with new EAP methods but points out that we have a lot of existing methods. Glen and I had a long discussion about channel binding in EAP vs channel binding as part of the secure association protocol. That was a very useful discussion. The interesting question is what favors one approach vs another. Channel binding always requires changing the client and the home AAA server/EAP server. Using a SAP requires: 1) changing all the NASes 2) Specifying an extension to each lower layer that may be used 3) Specifying AAA transport for this extension. [As an aside, Glen proposed a mechanism for doing this at the AAA layer that should get written up somewhere. I thought it was quite clever and easier than any attempt to do this I had seen before. Of course I'm a relative novice when it comes to AAA.] Using channel binding inside EAP requires: 1) Changing/specifying channel binging for the EAP methods in use. For most of the applications I care about (with the exception of the EAP for non-network-access use case), avoiding having to change the NAS is a huge advantage. Also, from where I sit, not having to update the link layers is a big deal. However, the conversation was really useful because I now understand situations in which both of those assumptions about complexity of change would be different. So, here are some ideas going forward for areas I'd like to improve the draft: 1) The introduction does discuss use cases. However I don't think it does a particularly good job of describing concrete use cases; I'd like to provide some explicit examples. 2) The draft doesn't currently motivate the secure association protocol version of channel binding. I will admit that my reaction when I read that section of the draft was roughly that's a stupid idea there to
Re: [Emu] Summary of Federated Authentication BOF at IETF 77
Alper == Alper Yegin alper.ye...@yegin.org writes: authentication. The first is that EAP only authenticates the home realm; it does not authenticate what service youùre going to. So you might try to connect to your e-mail and end up giving something access to your stored files and pictures instead. That is, EAP has aphishing exposure in the federated context. If the only thing you can get by using EAP is network access, that exposure is only moderate. However in a fully federated environment that is a huge exposure. Moonshot will address thisproblem by using EAP channel binding Alper Channel binding is a term that is specific to the network Alper access application. For generic applications, we need Alper something else. Basically we are talking about authorization Alper parameters. App server has verified that you are Joe, and Alper you are allowed to use X, Y, Z apps/resources. This Alper authorization aspect goes beyond authentication (as in Alper extensible authentication protocol). This aspect may not be Alper easy to stick in the EAP. When I'm speaking of channel binding, I am not speaking of that sort of authorization. i'm speaking of giving the peer (not the NAS) confidence that the peer has connected to the NAS that the peer intended to connect to. I argue that when you generalize the NAS so that the NAS is a mail server, web server, or other app server, the question of which generalized NAS you're talking to is far more important than in the network access application. I believe that both RFC 3748 and draft-ietf-emu-chbind define this problem as channel binding. At one level, I don't care what we call it: we need to solve it. Alper and by doing the necessary work to make that a viable solution. The second concern is that interoperability is reduced when you have multiple authentication approaches for the same problem. If EAP is going to be used for application authentication, we need to understand how it relates to the rest of the application authentication metasystem. Moonshot proposes such a relationship, addressing my objection. Alper Not sure I understand. EAP-based scheme will still appear as Alper N+1st method. I don't understand your comment here. It may be something better discussed over the phone or something, although I'm happy to keep e-mailing on this. 8. Applicability Considerations Section 1.3 of RFC 3748 provides the applicability statement for EAP. Among other constraints, EAP is scoped for use in network access. This specification anticipates using EAP beyond its current scope. The assumption is that some other document will discuss the issues surrounding the use of EAP for application authentication and expand EAP's applicability. That document will likely enumerate Alper Is this document available? Which document? The proposed applicability statement for EAP? No, I'm hoping that we can work on that in the WG we charter; would you be interested in helping with that document? Or are you talking about draft-howlett-eap-gss? If so, yes, that is in the ID repository? Or were you talking about the feasability analysis? If so, there is a link from www.painless-security.com/blog and will soon be a link from www.project-moonshot.org . I'd definitely be interested in a discussion with you about these issues. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Summary of Federated Authentication BOF at IETF 77
Alper == Alper Yegin alper.ye...@yegin.org writes: Alper Was this discussed? Is there a proposal to expand the Alper applicability statement of EAP now? Where do we draw the new Alper line now? I've certainly been thinking about it. Quoting http://www.painless-security.com/blog/2010/02/12/moonshot1: Itùs interesting that Iùm advocating EAP for application layer authentication. When I was a Security AD, I made a strong statement that EAP must only be used for network access. Iùve been fairly consistent about that since then. I think there are two huge problems with using EAP for application authentication. The first is that EAP only authenticates the home realm; it does not authenticate what service youùre going to. So you might try to connect to your e-mail and end up giving something access to your stored files and pictures instead. That is, EAP has aphishing exposure in the federated context. If the only thing you can get by using EAP is network access, that exposure is only moderate. However in a fully federated environment that is a huge exposure. Moonshot will address thisproblem by using EAP channel binding and by doing the necessary work to make that a viable solution. The second concern is that interoperability is reduced when you have multiple authentication approaches for the same problem. If EAP is going to be used for application authentication, we need to understand how it relates to the rest of the application authentication metasystem. Moonshot proposes such a relationship, addressing my objection. In addition, if you take look at the work proposed for standardization spelled out in the feasibility analysis,I propose that we need to revise the applicability statement for EAP. Quoting draft-howlett-eap-gss-00: 8. Applicability Considerations Section 1.3 of RFC 3748 provides the applicability statement for EAP. Among other constraints, EAP is scoped for use in network access. This specification anticipates using EAP beyond its current scope. The assumption is that some other document will discuss the issues surrounding the use of EAP for application authentication and expand EAP's applicability. That document will likely enumerate considerations that a specific use of EAP for application authentication needs to handle. Examples of such considerations might include the multi-layer negotiation issue, deciding when EAP or some other mechanism should be used, and so forth. This section serves as a placeholder to discuss any such issues with regard to the use of EAP and GSS-API. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Summary of Federated Authentication BOF at IETF 77
I'm told there were around 30 people in the room. That seemed like a good turn out for Thursday at 9 PM. Many of the participants had already read some or all of the proposed documents. I presented a problem statement based on providing federated authentication for non-web applications. Two solutions were presented. I presented work on Moonshot, a technology that combines EAP, GSS-API, RADIUS and SAML to solve the problem. Eliot Lear and Klaas Wierenga presented a simpler solution that uses browser-based SAML and Open ID. The sense of the room was that these solutions compliment each other. Moonshot requires more infrastructure and client configuration but provides several advantages. The browser-based solutions are something that requires fewer client changes. Volunteers were collected from the EAP, GSS and RADIUS communities who would be interested in working on these problems. Some of the work discussed, possibly especially including the Open ID and SAML browser-based solutions may be able to progress in kitten. I and I believe several of the other Moonshot proponents would prefer to focus the Moonshot work in one working group. Other solutions could also be progressed in that group, although we should be careful not to slow down work that could progress quickly in kitten by moving it into an as-yet-unchartered group. There seemed to be strong support for going forward. However, several things to address in a BOF were raised with regard to the Moonshot work. * Steve Bellovin pointed out that we need to be very aware of the operational impact and how this fits with the operational model of the technologies that are used/extended. * Klaas pointed out that Moonshot involves changes to a lot of different components. We need to make sure that there are incremental advantages to each of these changes so they will be deployed: a system where there is no benefit until the end when all the peaces fall together is much harder to deploy. * Klaas pointed out that we need to consider the operational security around how RADIUS federations are deployed. If network access is not considered sensitive today, people may be more lax in the security surrounding their RADIUS infrastructure. If we use that infrastructure to secure more sensitive resources we need to have practices that tighten up the security of the infrastructure sufficiently. * Someone brought up that this is another one of those authentication proposals where user-interface is critical. While we should not lay out dialogues in the IETF, we're going to need to describe the usability aspects of this enough to increase the probability of a good security solution. People specifically asked to look at the following: * Complexity * What can't be handled with simpler solutions * Is Moonshot broad enough in scope? * The UI questions Since the bar BOF, there has been a lot of traffic on the list and work continues. We're definitely going to put together a BOF request for IETF 78. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Bar Bof on Federated Authentication Thursday at 9 PM during IETF week
Folks, I'm trying to get a room for the federated authentication bar BOF Thursday March 25 at 9 PM US Pacific time I've requested a room from the secretariat and Pasi said he would approve the request, so we'll see what their availability is. I plan on starting out with a brief presentation on the problem and solution architecture I'm working with, then we'll open it up to discussion. The goal of the discussion will be to determine if there is sufficient interest to have a BOF at the next IETF and to understand what steps we need to take between now and then. For the announcement of the proposal see http://www.ietf.org/mail-archive/web/emu/current/msg01363.html and for our mailing list see http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY Thanks for your interest, Sam Hartman Painless Security, LLC ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] [IETF I-D Submission Tool] New Version Notification for draft-howlett-eap-gss-00
This is one of the documents for the bar bof on federated authentication I sent mail about a couple of weeks ago. Discussion currently on moonshot-commun...@jiscmail.ac.uk. ---BeginMessage--- A new version of I-D, draft-howlett-eap-gss-00.txt has been successfuly submitted by Sam Hartman and posted to the IETF repository. Filename:draft-howlett-eap-gss Revision:00 Title: A GSS-API Mechanism for the Extensible Authentication Protocol Creation_date: 2010-03-01 WG ID: Independent Submission Number_of_pages: 19 Abstract: This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. The IETF Secretariat. ---End Message--- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed bar BOF on federated authentication for non-web applications at IETF 77
I've been working with JaNet(UK) on providing a federation solution for client applications such as mail readers, filesystem clients, XMPP clients and the like. There are fairly good solutions such as Open ID, Information Card and SAML for web applications. Within an enterprise, you have Kerberos. JaNet(UK) runs one of the world's largest SAML federations. As their customers are beginning to take advantage of federated access for web applications they are also asking how they can gain the same flexibility for client-server applications. This customer demand appears to have traction across the entire European academic community. I suspect that it may find traction within enterprises and other environments. We'd like to have a bar BOF at IETF 77 in California with a goal of an actual BOF this summer in Europe at IETF 78. We invite you to join our mailing list at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community where we can discuss timing. We plan to discuss the general problem and a proposed solution at the bar BOF. I've already prepared a feasibility analysis for JaNet(UK)'s solution; the analysis does discuss the problem some, gives an outline of the solution and discusses technical issues and required standards work in detail. By IETF we'll have a use case paper, an internet draft on the solution,and a slide set. we look forward to your input. You can find a bit more detail on my blog at http://www.painless-security.com/blog/2010/02/12/moonshot1 You can find the feasibility analysis at http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf Thanks, Sam Hartman Painless Security ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan Sam Hartman wrote: The whole composed / decomposed thing is Alan a nightmare for passwords. And one the emu working group needs to deal with. Alan RFC 3629 says that overlong sequences are invalid: AlanImplementations of the decoding algorithm above MUST Alan protect against decoding invalid sequences. For instance, a Alan naive implementation may decode the overlong UTF-8 sequence Alan C0 80 ... Alan I would therefore follow the lead of the UTF-8 experts, Alan and suggest that decomposed characters are overlong, and Alan thus invalid for the purposes of EMU. Therefore, UTF-8 Alan sequences must consist solely of composed characters. This will be my last message on the subject. There are approaches to consider in this space, but it's not that simple. If only it were that simple. One of the simplest problems with this approach is that not all the combined characters that you need actually exist. Another potential issue is that I think normalizing towards decomposed may be easier than normalizing towards combined. --Sam ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan My opinion is that normalization belongs at the edge, Alan which generally also has information about the language and Alan locale. Once normalization is performed, the password can Alan be sent over the wire *without* language or locale Alan information to the server. This isn't a bad idea. Think though about how it interacts with password databases used for multiple purposes. You sometimes get into situations where you need to do normalization both at the client and server. That too can be OK. You just need to think it all through when writing your specs. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
Alan == Alan DeKok [EMAIL PROTECTED] writes: Alan Hao Zhou (hzhou) wrote: I think publishing a widely deployed EAP method is orthogonal to publishing a new method meeting EMU charter. I agree publishing the existing method as deployed is something needs to be done quickly. I am still doubtful that adding the extra stuff required to meet the charter (crypto-binding, crypto-agility, synchronized result indication, internationalization), Alan I'm not sure why internationalization is an issue. This Alan came up in RADEXT a while ago. The consensus at the time Alan was that RFC 4282 discusses internationalization of the NAI, Alan and that passwords don't need to be internationalized. Alan Internationalization matters for *display* to end users. Alan Internationalization is about *languages*. Passwords aren't Alan displayed, and they aren't words in any language. They're Alan opaque tokens that users have memorized, and can repeat on Alan demand to demonstrate secret knowledge. The consensus of the SASL and Kerberos communities has been different. In particular, these communities believe that it is strongly desirable that the same password when entered on two different systems actually work. To get that, you need to deal with issues like normalization. Otherwise, if you use a system with input methods that produce combined characters you will get different results than if you use input methods that produce decomposed characters. At some level, this is an implementation issue for the server. However to support the server, you definitely need to label the character set, discuss any normalization that the client should do (often none) and set interoperability goals. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] Chennal binding
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: Lakshminath I would like to see the crypto-binding stuff (not Lakshminath compound binding -- as others have noted, we don't Lakshminath have consensus on that topic) and extensibility (how Lakshminath to add new attributes) specified. I'd really appreciate it if someone would think hard about the interactions of draft-housley-aaa-key-mgmt and channel binding. I'd like to understand whether we can meet all the requirements of that BCP without channel binding and if not, what we need to do about it. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Crypto-binding in TTLS-v0
As a matter of process, if EMU is going to satisfy its charter item regarding passwords, it will need to refer to a standards-track EAP type of some kind. The existing process for getting EAP methods published as RFCs does not result in standards track RFCs. So, if EMU is going to base its work on something existing, it is probably important for EMU to take on the entire method. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes: I think that having a single abstraction that can describe what went by multiple names in different areas can be very useful because it facilitates cross-area communication. And missing an opportunity to point out how two things are more similar than they look would help perpetuate a perception that those two things are more different than they actually are. Lakshminath I can see your point of view. The other thing to Lakshminath worry about is that the more we try to cover under a Lakshminath single abstraction, the more watered down it might Lakshminath become to satisfy all viewpoints of applicability to Lakshminath all of the domains. In fact, I find the requirements Lakshminath and recommendations in the draft troublesome. Lakshminath As I thought about it, perhaps here is something that Lakshminath might make sense: Lakshminath Define channel binding so that we can cover all uses Lakshminath of that term. Define properties and specify how one Lakshminath can achieve those properties. Not sure this next one Lakshminath needs to be done in the current draft, define which Lakshminath properties apply to which protocol. Alternatively, Lakshminath different protocol drafts may specify which of the Lakshminath properties are required or recommended in each case. Lakshminath Does that make sense? That makes sense; I think that is exactly what we're doing. I continue to believe, having read all the messages here that my original text is very close to correct in describing the EAP channel bindings problems. I'd love to talk to someone off-line to discuss this, because there is some obvious confusion somewhere. The more I read what you, Bernard and Charles say, the more I'm convinced that I agree with your description of EAP and that my text is correct. The more I talk, the more you're convinced that my text is wrong. We're talking past each other somehow. ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
[Emu] Re: Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings
Nicolas == Nicolas Williams [EMAIL PROTECTED] writes: Nicolas Also, I think my draft's definition of end-point channel Nicolas bidning needs to be tightened just a bit: not only must Nicolas the end-point IDs be cryptographically bound into the Nicolas channel, it must also be the case that the IDs Nicolas meaningfully identify the channel end-points -- that is, Nicolas that one nodes cannot assert the same ID as another Nicolas without sharing credentials with it. I think my text Nicolas implies this but does not make it sufficiently explicit. Be careful. A DN given a trust anchor seems like a find end-point identifier. However two nodes can share the same DN without sharing the same credential. Under 3280 rules either the CA issued a certificate it should not have issued or the two nodes are the same subject. That's strong enough for the channel binding to be useful even though the nodes may not share a credential. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] Re: Next Steps on Passwd-based EAP Methods
Hannes == Hannes Tschofenig [EMAIL PROTECTED] writes: Hannes Hi all, before we spend more time considering EAP Hannes tunneling methods like PEAP and TTLS I would like to hear Hannes the opinion of our ADs on this subject. So far, the Hannes working assumption was that EAP methods that tunnel EAP Hannes are outside the scope of the working group. These Hannes statements were also repeated during the IETF#68 EMU WG Hannes meeting by our ADs. I at least don't recall objecting to a tunnel method. If you're going to do a tunnel method you do need cryptographic binding when tunneling something that generates a key. Bernard objected rather strongly to a tunneled method. Note that I am not saying you should go in the direction of a tunneled method; a simple password over tls method is a fine approach. I just don't recall me making an AD level objection to tunnels. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
