Re: [Emu] [saag] Feedback on Salted EAP draft
Hi, Is there interest in reviewing this draft? Sam pointed out the importance of moving this work forward, it would be helpful to have volunteers to review the work and also to understand the level of interest (if any) before this goes forward as AD sponsored. FWIW, I read and commented on the draft in its -00 state. I'm still very interested in this document as it enables contemporary real-life password databases to work with pwd. I'm still happy to be the doc shepherd once the time has come to move the document forward. Greetings, Stefan Winter Thank you! On Fri, Mar 27, 2015 at 1:34 PM, Sam Hartman hartmans-i...@mit.edu mailto:hartmans-i...@mit.edu wrote: Kathleen == Kathleen Moriarty kathleen.moriarty.i...@gmail.com mailto: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. -- Best regards, Kathleen ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ 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
for the use of anonymous outer identities, the desired outer identity should also be (re-)encoded in UTF-8 encoding before being put into the EAP-Response/Identity. I would add or allow the provisioning of an EAP-Response/Identity field independent form the EAP method user identifier Well... that degree of freedom exists - outer ID *is* independent from the EAP method's user identifier. I'm not sure what the effect of this (third!) notion of (non-)identity could add? The example of the 3GPP vs. realm.example shows that there may well be *no* common EAP-Response/Identity which actually fits all configured EAP types. Section 5 It may be worth noting that supplicants should try the most secure EAP methods first (i.e. ones with anonymous outer identity). If those fail, they should proceed to more insecure methods. This prevents leakage. Good idea! Also, supplicants could cache information about successful authentications. If the system appears to be the same as one where EAP method X previously worked, it makes sense to start off with EAP method X. How the supplicant determines that this is the same system is a subject for discussion. Interesting thought, and a bit complex. I suggest we discuss this when the draft gets adopted in ... some working group. Suggestions welcome :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
Hello, I've just submitted an -00 on a topic that we've been struggling with in ABFAB recently (but which exists in every EAP-over-AAA scenario, not limited to ABFAB). http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. The issue touches multiple areas and working groups (EAP, EAP methods, RADIUS, Diameter) so I had to do a guesstimate for a proper home. I would think radext is the best match, cc'ing abfab and dime, and also emu even though it's shutting down). If you recall those in-depth discussions about fixing either EAP methods to use UTF-8, or why EAP Identity would need to be restrained to UTF-8 even if a method doesn't do it, then yes: the draft is about that. In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057: Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. Which was enough to get the document through IESG, but this should better be fixed more generally for every EAP use case; hence this new draft. It's short and concise - I'd appreciate if you could give it a read and comment. If there's still free time on the agenda, I would also merrily discuss it in London. Greetings, Stefan Winter P.S.: Don't miss my other submission about an EAP Configuration File Format, which I've been told to submit to ops-area/opsawg: http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Annoucement here: http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html Original Message Subject: New Version Notification for draft-winter-radext-populating-eapidentity-00.txt Date: Fri, 14 Feb 2014 00:43:29 -0800 From: internet-dra...@ietf.org To: Stefan Winter stefan.win...@restena.lu, Stefan Winter stefan.win...@restena.lu A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-radext-populating-eapidentity Revision: 00 Title: Considerations regarding the correct use of EAP-Response/Identity Document date: 2014-02-14 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt Status: https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentity/ Htmlized: http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for TEAP
Hi, Ok, there is a misunderstanding here. What I mean is the EAP server not trusting the ID Management System. That might seem a bit odd, but imagine an EAP server trying to authenticate Kerberos against a remote KDC for example. That's indeed a different meaning from what I thought it would be. In that case, the error message makes a lot more sense. Again this was meant to signal a clock skew between the EAP server and the ID Management System. Okay. Stefan, I would apply the same reasoning that you give in your first response in this message. I.e., it is precisely because EAP doesn't provide the signalling, even though the EAP server is fully aware of the error condition, that we can substitute with TEAP-based signalling. ... in the cases where luck has it that we know on the TEAP layer what happened elsewhere. Fine for me :-) Probably. Others here besides me are certainly better informed regarding CBs, but: 5.3.1 has success and failure. The fact that it was requested but not supplied is information which is local to the EAP peer; it knows that it requested it, and knows that it didn't get it - no protocol signalling involved here. Aren't these orthogonal issues? RFC 6677 signalling only refers to the CB binding used by the inner method, and not between the TEAP's tunnel and inner method. I'll let the CB gurus pick up that one. :-) [Joe] wouldn't these be better handled using the Password authentication TLVs? Well, if we are going to specify lots of extended responses as above, then these messages here would fit into them equally well. Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV don't seem to have signalling of their own for these things? Sorry, I don't follow this. Could you elaborate please? Joe wants the error messages to be stuffed into the password authentication TLVs. These are: Basic-Password-Auth-Req TLV Basic-Password-Auth-Resp TLV I'm claiming that this can't work, because the server may discover that its backend is inaccessible only after it has sent its Req. Remember that Req is sent from the *server* to the *peer* as in: Server: Req: User, what's your username and password? Server: Resp: johndoe/stupidpassword Server: ... looking up that combo ... Oh! My backend is gone! Since both Req and Resp have already played their part, none of these two TLVs can carry an error message at this point. The generic Error TLV that we're discussing in this thread is the only place to put such error messages in. Greetings, Stefan Winter Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ 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
Hi, Stefan This limits the scope of the error conditions to cases where Stefan TEAP has all in its own hands - which I believe is limited Stefan to the Optional Password Authentication of chapter 3.3.2. DIsagreed. AAA servers don't signal all of these up, but AAA servers often signal a number of these. For example in Freeradius I could actually figure out a number of these even across an inner tunnel and could easily expand the server to do better than that. However if you have nothing else then you are left with inner method error. Yes, it occured to me afer sending that my mind model was maybe a bit too strict: there is no /protocol/ way for things to transpire from inner to outer; but there may be be other means (like shared memory in the server process) *if* inner and outer terminate at the same server. If the inner method is proxied elsewhere, then we're out of luck in terms of getting specific error conditions from the inner method; proper protocol-based signaling would then be required but doesn't exist. I guess it comes down to wordsmithing to express this correctly; like will work for TEAP's simple password auth, and *may* work for inner EAP, if inner and outer termination point are co-located, or otherwise have an unspecified out-of-band protocol of their own for signalling error conditions between inner and outer termination point. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for TEAP
for unspecified reason Again something we can do for password auth, but not if inner EAP is used. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Improving EAP usability and deployment security: call for participants
Hello, (and sorry for being slightly off-topic) I'm writing this mail as someone who is heavily involved with deploying Enterprise WiFi to millions of end users, belonging to thousands of independent administrative domains, all of which have their own EAP deployment and associated supplicant configuration needs - the eduroam roaming consortium (you may want to look at http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 for a description of the consortium and its inner workings). Over the ten years of operation of eduroam, we have seen the good, the bad, and the ugly of supplicants, and realised that even if there are excellent technical specifications (IEEE 802.11i, IEEE 802.1X, EAP, various EAP types, RADIUS, ...), the real world deployments of these specifications aren't always as perfect as they should be. One of the biggest complaints we hear from end users is the effort of initial supplicant setup, and sometimes the sad fact that users are either DoSed because their device doesn't support any EAP type which matches their organisation's deployment; or that the supplicant setup is only possible with leaving gaping security holes open (e.g. not possible to specify which CA issued the EAP server certificate!). We believe that there is a lot of potential in the implementation space to take EAP peers - 802.1X supplicants - to a new level of a) implementation completeness b) user-friendly interactive configuration c) automated configuration deployment (a.k.a. profiles) There is currently a call for participants in a European project where one of the topics on call is IEEE 802.1X and EAP - Improving Implementation Completeness and User-Friendliness. It's call #16 of the list on this page: http://www.geant.net/opencalls - Call Text My employer and other organisations are in the process of forming a consortium to reply to this call and we are looking for further partners - in particular industry partners who implement supplicants and ship them in their products; the main goals of the consortium-to-be is to develop guidelines for UI design, cornerstones for implementation of EAP in supplicants, and a standard interface for conveying EAP configuration data (EAP metadata) to the supplicants for automatic configuration provisioning - and of course to have partners who are willing to implement these guidelines! Why should you join? The benefit for you as a supplicant implementor to join the project is that you'll get valuable input and suggestions for improving your product - which will ultimately give you an advantage on the market compared to other implementations which don't participate. The time your workforce spends in this project will be partially compensated for according to normal European Commission project rules (I'm not a finance guy, so just as a non-authoritative indication: with exceptions, only European entities can be compensated; up to a maximum of 50%-75% of the workforce expenditure plus overhead (subject to several conditions)). The slide deck of the Information Day regarding this call which was held on 19 April may give you more specific detail; slide 54 f. are about this particular objective. Also check out the FAQ! http://www.geant.net/opencalls - Information Day http://www.geant.net/opencalls - FAQ If you or your company are interested in joining this consortium, please get in touch with me (off-list; stefan.win...@restena.lu ). Note that while I'm recruiting for this project-to-be, my company will very likely not take the consortium leadership role but be a mere member of the consortium. Thanks for your attention! For those who care, a number of real-life imperfections is below. Greetings, Stefan Winter There are numerous examples of imperfection; I do not believe that a single perfect supplicant exists. So, when I give a few examples below please understand them as random specimen of the world out there, not as a particular nameshame for the company names in these examples. It just goes to show that there is work in this for everyone :-) Example 1: EAP identity has a 1:1 mapping with an SSID == Apple, Inc. has a very powerful tool for deployment of WiFi configuration profiles to recent Mac devices and i* mobile devices using their mobileconfig file format. Unfortunately, the file format assumes that the SSID is the primary discriminator of networks, and that an EAP identity is a property of an SSID. As a consequence, if an Enterprise WiFi deployment uses multiple SSIDs, all to be used with the same EAP identity, these need to be configured independently. This is not just a question of deployer's convenience when crafting the config files: it transpires down to the end user, who has to enter his username and password n times while installing the profile, once for each SSID in the set - even if the account information is identical. This approach also makes uses in the new Hotspot 2.0 / IEEE 802.11 Interworking
Re: [Emu] Client Auth with TLS
Hi, Actually even if the client is authenticated as part of the TLS tunnel establishment, NEA data can still be passed inside TEAP tunnel. It is designed to carry additional data in Phase 2. The Current TEAP draft supports both of these modes, as in Section 3.2: Thanks for the explanation. Well, if it supports both then that opens space for misunderstandings. When configuring protected client auth, one implementation might on the wire choose to do protected client-side auth within the TLS handshake, but another might expect an inner EAP-TLS instead. I fail to see why supporting *both* modes of operation is required. From my (non-implementer's) point of view, I see two code paths to achieve the same goal here. In terms of implementation complexity, it would appear to me that using inner EAP-TLS makes the client cert exchange yet another inner EAP method (ideally able to share code with other inner EAP method's session establishment), while a TLS-handshake operation creates a special case to be handled differently. Greetings, Stefan Winter TEAP implementations MUST support client authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2 http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-03#section-3.2 . The EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional exchanges carried out in Phase 2. The TEAP tunnel protects peer identity information exchanged during phase 2 from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel prior to phase 2. TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current cipher suite. This allows support for protection of the peer's identity when using TLS client authentication. It properly doesn't describes the TLS exchanges as detailed as in EAP-TLS RFC, but something we could improve if desired. On 10/9/12 10:23 AM, Stefan Winter stefan.win...@restena.lu wrote: Hi, I think it is worthwhile to support an mode of operation that supports peer privacy. I've seen this implemented in tunnel methods in two different ways. One with renegotiation as described below and the other as an inner EAP-TLS exchange after an anonymous outer exchange. I don't really have a strong opinion as to which is better at this point. It seems that using an inner EAP-TLS may be more flexible and would offer the same security properties and might be a simpler model. Any opinions on the list? We have a couple of EAP-TLS realms which are also interested in NEA. I usually tell them that NEA data can't be put into the EAP channel with EAP-TLS, and that that is bad luck for them :-) If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP would/might allow for carrying extra attributes besides the cert exchange - thus enabling NEA-like exchanges. If my thinking isn't borked, that would mean I'd rather support inner EAP-TLS to enable these usages. Greetings, Stefan On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: Stefan, Thanks for the input. For the authors, Does this need to be documented as a mode of operation for TEAP or are we going to say that this is not a supported mode? Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Stefan Winter Sent: Wednesday, October 03, 2012 11:10 PM To: emu@ietf.org Subject: Re: [Emu] Client Auth with TLS Hi, 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client credential exchange (for client privacy protection reasons). I didn't ever see it used (anyone?), but it's clearly a foreseen mode of operation. The text describing this is in section 2.1.4: ...In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing
Re: [Emu] Client Auth with TLS
Hi, I think it is worthwhile to support an mode of operation that supports peer privacy. I've seen this implemented in tunnel methods in two different ways. One with renegotiation as described below and the other as an inner EAP-TLS exchange after an anonymous outer exchange. I don't really have a strong opinion as to which is better at this point. It seems that using an inner EAP-TLS may be more flexible and would offer the same security properties and might be a simpler model. Any opinions on the list? We have a couple of EAP-TLS realms which are also interested in NEA. I usually tell them that NEA data can't be put into the EAP channel with EAP-TLS, and that that is bad luck for them :-) If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP would/might allow for carrying extra attributes besides the cert exchange - thus enabling NEA-like exchanges. If my thinking isn't borked, that would mean I'd rather support inner EAP-TLS to enable these usages. Greetings, Stefan On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: Stefan, Thanks for the input. For the authors, Does this need to be documented as a mode of operation for TEAP or are we going to say that this is not a supported mode? Jim -Original Message- From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Stefan Winter Sent: Wednesday, October 03, 2012 11:10 PM To: emu@ietf.org Subject: Re: [Emu] Client Auth with TLS Hi, 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client credential exchange (for client privacy protection reasons). I didn't ever see it used (anyone?), but it's clearly a foreseen mode of operation. The text describing this is in section 2.1.4: ...In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in response to the initial certificate_request from the EAP-TLS server. An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead, it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the peer sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc. For the calculation of exported keying material (see Section 2.3), the master_secret derived within the second handshake is used. An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session. There is a sequence diagram shortly afterwards which shows clearly that the first negotiation ends with a 'finished' and then immediately a new 'hello_request' - all in one EAP message. Greetings, Stefan Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Client Auth with TLS
Hi, 3. The client provides the certificate in a protected manner - I had a problem at this point because I don't know enough TLS to properly go through this scenario, and I could not really read documents while driving. If the encrypted certificate extension was used, then there is no issue as the protected certificate would be passed in the initial handshake. However if the client starts the negotiation and then restarts it after it is encrypted, I don't know if this occurs before or after the finish message. If it starts after the finish method then there is an issue with having the server close an anonymous session if the client is then going to provide the certificate encrypted. Help on how this works would be appreciated. FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client credential exchange (for client privacy protection reasons). I didn't ever see it used (anyone?), but it's clearly a foreseen mode of operation. The text describing this is in section 2.1.4: ...In order to avoid disclosing the peer username, an EAP-TLS peer configured for privacy MUST negotiate a TLS ciphersuite supporting confidentiality and MUST provide a client certificate list containing no entries in response to the initial certificate_request from the EAP-TLS server. An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead, it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the peer sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc. For the calculation of exported keying material (see Section 2.3), the master_secret derived within the second handshake is used. An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session. There is a sequence diagram shortly afterwards which shows clearly that the first negotiation ends with a 'finished' and then immediately a new 'hello_request' - all in one EAP message. Greetings, Stefan Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Suggestion for eap-tunnel-method on Phase 1 failure
Hi, Stefan: Actually this is already specified in TEAP. Section 3.6.1, states: If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer should send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an TEAP request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the TEAP conversation to be restarted or it may terminate the conversation by sending an TEAP response with an zero-length message. So the peer should send back a TLS alert, like unknown_ca, certificate_unknown, bad_certificate etc to alert the server that the server certificate failed authentication. D'oh, I only looked in 3.2 Phase 1 and overlooked that text further down. Sorry for the noise... and a +1 that this is the right response to send! Stefan On 3/27/12 5:25 AM, Stefan Winter stefan.win...@restena.lu wrote: Hello, during a discussion yesterday with some folks on EAP-PWD, we hit an issue which I think is also of relevance for TEAP. The issue is: assume an ongoing TEAP tunnel setup, the server sends a certificate, but it's not the one the client expects. With the current tunneled EAP methods (and also PWD in its current form), the client will recognise that it doesn't like the remote end and will stop communicating immediately. For the client, there is no negative side-effect to that. It can simply discard all EAP session state and that's it. The server side though only sees its last EAP-Request going out to the EAP peer, and will wait for a response. The response will never come, but the server needs to keep EAP session state for the conversation until it hits a (potentially very long) timeout. The underlying problem is that the EAP state machine doesn't finish, it just hangs mid-air. One end knows and discards, the other doesn't. This means the server will pile up useless state information. It also makes debugging client problems harder, because there is no final Reject going out to the client (when doing EAP over RADIUS, often Accepts and Rejects are logged, but intermediate Access-Challenges aren't). If there were a bailout trailer to end a failed server ID verification, things could get much cleaner in that respect. I'm not sure how exactly to encode it; maybe a EAP-Response with a TLS alert. Upon receiving the alert, the EAP server could craft its final EAP-Failure, send it out, and discard session state. Of course one argument is: if the ID verification failure is because you were connecting to a rogue server, you as a client shouldn't be so kind to help the rogue clean up his state. While that's true, verification failures are extremely often simply due to user misconfiguration (typo in expected server name, wrong CA box ticked) or subtle mis-configuration on the server side (not adding the TLS Web Server OID as Extended Usage, which the Windows supplicant chokes about). In these cases, it is quite helpful to make the server actively aware that something went wrong. I wonder if something like that could be considered for TEAP. In eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic that guesses that it's an ID verification problem, but only does so in debug mode. And it being a heuristic, sometimes it's just wrong. So getting a clear The client didn't like me message to act upen would be a good thing IMHO. Greetings, Stefan Winter ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Suggestion for eap-tunnel-method on Phase 1 failure
Hello, during a discussion yesterday with some folks on EAP-PWD, we hit an issue which I think is also of relevance for TEAP. The issue is: assume an ongoing TEAP tunnel setup, the server sends a certificate, but it's not the one the client expects. With the current tunneled EAP methods (and also PWD in its current form), the client will recognise that it doesn't like the remote end and will stop communicating immediately. For the client, there is no negative side-effect to that. It can simply discard all EAP session state and that's it. The server side though only sees its last EAP-Request going out to the EAP peer, and will wait for a response. The response will never come, but the server needs to keep EAP session state for the conversation until it hits a (potentially very long) timeout. The underlying problem is that the EAP state machine doesn't finish, it just hangs mid-air. One end knows and discards, the other doesn't. This means the server will pile up useless state information. It also makes debugging client problems harder, because there is no final Reject going out to the client (when doing EAP over RADIUS, often Accepts and Rejects are logged, but intermediate Access-Challenges aren't). If there were a bailout trailer to end a failed server ID verification, things could get much cleaner in that respect. I'm not sure how exactly to encode it; maybe a EAP-Response with a TLS alert. Upon receiving the alert, the EAP server could craft its final EAP-Failure, send it out, and discard session state. Of course one argument is: if the ID verification failure is because you were connecting to a rogue server, you as a client shouldn't be so kind to help the rogue clean up his state. While that's true, verification failures are extremely often simply due to user misconfiguration (typo in expected server name, wrong CA box ticked) or subtle mis-configuration on the server side (not adding the TLS Web Server OID as Extended Usage, which the Windows supplicant chokes about). In these cases, it is quite helpful to make the server actively aware that something went wrong. I wonder if something like that could be considered for TEAP. In eduroam, we sort of miss it in PEAP at least. FreeRADIUS has a heuristic that guesses that it's an ID verification problem, but only does so in debug mode. And it being a heuristic, sometimes it's just wrong. So getting a clear The client didn't like me message to act upen would be a good thing IMHO. Greetings, Stefan Winter ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Hi, Actually, I was pleasantly surprised that Internet Tunneled EAP Method turned out to be ITEM but in any case...I'm sure that there is no policy except maybe having a little fun ;-). Maybe that should be against policy? I do think that EAP-TUNNEL is both grammatically incorrect (since tunnel is a common noun it shouldn't be capitalized, let alone ALL CAPS :-). I didn't want to violate more common thinking about naming by using non-capitals! EAP-Tunnel would be just as fine for me. Also, I wonder if it isn't a bit too generic: there are a whole bunch of PEAP clones (sorry, tunneled methods) already: TTLS, FAST, etc., all of which could be reasonably referred to as EAP TUNNEL. That's right. We should prefix it as */the/* EAP Tunnel to make people aware that it's the one-and-only type to be used. Yes, I'm actually dreaming that the deployed world out there would settle to use just one in a distant future... Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Hi, two suggestions for the new name (assuming that the Deciders establish that a new type is a good idea), just to get the ball rolling: Tunneled Extensible Authentication Method (TEAM, an oldie but goody) and Internet (or IETF) Tunneled EAP Method (ITEM). Crazy thought: how about EAP-TUNNEL? Yes, I know, not an acronym, just a plain old English word which makes sense on its own - which probably breaks several but it needs to be a four-letter acronym, preferably a nicely sounding one, with a strange expansion which is obviously reverse-engineered from the acronym to sound cool policies. Stefan ... ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77
Hi, Agreed. However, SSIDs are *likely* to be unique within a roamin consortium. This is because the parties talk to each other, and can complain when the SSIDs are unknown, or re-used. Umm. We use the SSID eduroam wherever possible for brand recognition, but even we have to deviate from that at times. The big reason being: two hotspots have overlapping coverage, and client devices get confused when the same SSID has different IP subnets. Proprietary extensions (Cisco controllers and LWAPP most notably) can be a way around this, but generally, eduroam-$FOO can show up at places, with arbitrary values for $FOO. Other reqasons also exist; but I won't bother you with them here. I don't think we are unique with these sorts of considerations; and I don't think it's safe to assume that everybody knows all SSIDs throughout a consortium. Greetings, Stefan Winter Assuming that the SSID is actually in the Called-Station-ID Attribute (see above) and that the NAS didn't just lie in the RADIUS message, too (given that there is no way to detect such a lie in a1 hop AAA scenario) and that there is no collusion between X Z. We seem to be assuming a _lot_ of honesty from our thieves. Yes. There are mitigating circumstances. AAA relationships leverage trust. Continued trust depends on the parties continuing to meet expectations. Lying about SSIDs violates trust. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77
Hi, 3580 says Called-Station-Id SHOULD include the SSID. Most APs do include the SSID. s/Most/Some There's a painful variety in what comes inside Calling-Station-Id, which is *very* unfortunate. A set of RADIUS attributes to convey things like the SSID in a proper place would be very handy (IEEE 802.11 attributes draft in radext!). And a FIXED syntax about MAC addresses in Calling-Station-Id, too. The SHOULD canonical form that you both quoted isn't honoured by many. Greetings, Stefan Winter However, SSIDs are *likely* to be unique within a roamin consortium. This is because the parties talk to each other, and can complain when the SSIDs are unknown, or re-used. What parties? The BSSs? Why? The parties in a roaming consortium talk to each other. There are mitigating circumstances. AAA relationships leverage trust. Continued trust depends on the parties continuing to meet expectations. Lying about SSIDs violates trust. But fraud doesn't? Yes, fraud violates trust. My original post included an example of fraud, stated why this was bad, and how channel bindings could help. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and authorization
Hi, The main limitation on bulk data transfer is that most EAP to RADIUS gateways (AP's, etc.) will terminate an EAP session after ~50 packets. This kind of thing drives me crazy. Why are their such policies? To prevent bulk transfer of data over EAP, among others. This would seem like a highly unlikely scenario, as in most system, someone privileged would have to install this rogue EAP module in the AAA system. Which might make sense in a roaming system if you want your users to get around being billed. Provider A and B operate WLAN hotspots, say with realm-based routing. A wants all his users to get access to B's hotspots, but without being billed for it :-) A sets up an EAP server with EAP-Fraud method which merely tunnels IP in EAP, installs supplicant with EAP-Fraud support on his clients. A's clients travel to a B-hotspot, and start a LONG authentication session to their A realm which is in fact normal IP communication via an IP proxy on their home EAP server. After an hour or so of merrily speaking IP, client indicates a wish to disconnect to home and the EAP server sends an Access-Reject. No bill, since the authentication failed. Just took a while. Greetings, Stefan Winter Please do not build EAP session breaking assumptions into AAA implementations. It would be useful to codify these experiences into an EAP best practices document. I've done it before... (I'll find the proceedings reference) An update is coming Dave. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments for draft-clancy-emu-chbind-02.txt
Hello, another possible use case would a home zone feature in service provider roaming scenarios: client sends information about which authenticator it is connected to, auth server signals back whether this is an authenticator which belongs to the user's own networking domain or is roaming. Greetings, Stefan Winter Another quick comment on the value derived by operators for deploying channel bindings -- channel bindings will give operators the ability to apply detailed authorization policies to EAP-based network access. Right now EAP is primarily just an authentication facility, and authorization is based on only information about the peer. Now authorization can also be based on information about the NAS, and the properties of the network to which the peer is connecting. Using channel bindings, for example, an EAP server could ensure that certain users only connect to 802.11 networks using AES for link-layer security or with certain SSIDs, for example, while other users could connect to any network. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical computer engineering, university of maryland Charles Clancy wrote: Hannes, Thanks for the comments. I'm working on a revision that addresses the fuzzy comparison issue. Certainly there's a cost to implementing channel bindings. EAP methods already support carrying the information, so the only changes would be to their implementations, which could be done incrementally. Having the authenticator send information to the EAP server for comparison doesn't work. The authenticator could simply provide the same false information to both the peer and server. The server needs some way to know whether the information the authenticator is sending is consistent with network policy. Therefore it needs a policy database. If it has the policy database, it no longer needs the authenticator to send this information to it during every transaction. The exact AVPs exchanged are still open for debate. The text there is mostly just a place holder. We need to know what types of things people thing are appropriate for validation. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical computer engineering, university of maryland Tschofenig, Hannes (NSN - FI/Espoo) wrote: * When I have to introduce this work to our AAA server folks then they will obviously ask me the following question: What is the benefit and what does it cost? As you mentioned in the operational considerations section there is cost associated with updating the EAP methods, putting new information into the AAA server database, providing additional policies into the AAA server to accomplish the authorization check. Now, the question really is whether folks are so concerned about the attack. I know the Lying NAS problem but the current text isn't scary enough. Have you ever seen some data that this attack is a real issue? In case you do then it would certainly be valuable information to convey this to the reader. * Reading the operational consideration section I get the impression that you consider that the AAA server database is populated with information about the access points and what information they are going to send to their peers. That might be one way of doing it. Another way would be for the AAA client to send the same set of parameters to the AAA server for comparison. * I am not sure how this fuzzy comparison would look like and how one would do that in practice. Does it mean that you just compare some parameters? Incorporating channel binding information into the key derivation functions would, for sure, get things to break even if the operator running the AAA server decides not to enforce it. It is good that you did not go for that approach. * Figure 1 I think that there is a possible information exchange missing in Figure 1. Shouldn't you also include an arrow between the Authenticator and the EAP server? * You write: The server MAY send the Cost-Information AVP from the Diameter Credit-Control Application [RFC4006] to the peer indicating how much peers will be billed for service. To my knowledge, this is not done for network access. This may be done for higher layer applications but AoC isn't really something that you find quite often... * IEEE 802.16 The case is somewhat different here since the access network can actually be authenticated. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue
Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Hi, Unfortunately, in at least some implementations, this is not the case. However, I'd be interested if there exist implementations that handle UTF-8 usernames. That would provide a reference to test a fix against. Indeed. After some more tests: Lancom Client Utility (same Windows XP instance): - behaviour is the same as the built-in supplicant: encoded on the wire in locale, cyrillic input possible but transscribed to ?. KNetworkManager (openSUSE Linux 11.0, 32-Bit) --- encoding of @müller.de to @m[0xC3][0xBC]ller.de (UTF-8, no punycode) encoding of cryillic characters to 2-byte encodings starting with d0 and d1 - looks like cyrillic area of UTF-8, no punycode in realm That looks like a good UTF-8 test case. KNetworkManager uses wpa_supplicant as a backend. Greetings, Stefan Winter P.S.: add $OPEN_SOURCE_SALES_PITCH_FOR_WPA_SUPPLICANT here ;-) -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Hi, * User-Name in GUI: some cyrillic letters * encoded on wire: all transcribed to the same symbol ? in ISO-8859-15 or similar encoding (which is not very helpful!) To get to the cyrillic letters, I installed multi-language support and complex IMEs, i.e. everything I could find in System Settings, thinking that it may help the system to move to UTF-8 encodings. [BA] What version of Windows was this? XP? Vista? Ah, sorry: XP SP3. Stefan Winter said: So... if for MS-CHAPv2, the behaviour for non-ASCII is unspecified, then it's alright for it to transscribe unexpected input to whatever character it likes. So not the supplicant is to blame, but rather the fact of life that MS-CHAPv2 lives in an ASCII world. Hmmm... is an update to 2759 in any way feasible? Considering its deployed base that appears difficult at best. [BA] I'm trying to understand why the ASCII limitation exists in the first place. Presumably there are security protocols out there that utilize UTF-8 encoded usernames or NAIs (perhaps after some normalization procedure), right? I don't have any insight on the amount of use of non-ASCII NAIs. For eduroam I can say: no usage known, and from last week on I will heavily discourage anyone from deploying that until the situation gets better. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Hi Bernard, thanks for providing more insight. What a mess. I got an encoding of ü ::= 0xfc, which hinted that the supplicant was not using UTF-8 but some locale (I expect it to be either ISO-8859-15 or Windows-1252, not that this matters).” [BA] Can you provide more details on the EAP implementation/operating system on which the test was conducted? I tried: Intel supplicant - * User-Name in GUI: @müller.de * encoded on wire: ü ::= 0xFC (ISO-8859-15/Windows-1252 of ü) * User-Name in GUI: tried cyrillic letters - couldn't even enter them in the dialog box in spite of Uzbek (Cyrillic) IME Windows built-in supplicant --- * User-Name in GUI: @müller.de * encoded on wire: ü ::= 0xFC (ISO-8859-15/Windows-1252 of ü) * User-Name in GUI: some cyrillic letters * encoded on wire: all transcribed to the same symbol ? in ISO-8859-15 or similar encoding (which is not very helpful!) To get to the cyrillic letters, I installed multi-language support and complex IMEs, i.e. everything I could find in System Settings, thinking that it may help the system to move to UTF-8 encodings. The transscript to ? now makes at least a little bit of sense to me, after your statement: EAP methods. For example, RFC 2759 (MS-CHAPv2) Section 4 states: “The Name field is a string of 0 to (theoretically) 256 case-sensitive ASCII characters which identifies the peer's user account name.” Yup. ASCII, **not** UTF-8! This actually can cause an authentication failure for a user with an NAI of [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. So... if for MS-CHAPv2, the behaviour for non-ASCII is unspecified, then it's alright for it to transscribe unexpected input to whatever character it likes. So not the supplicant is to blame, but rather the fact of life that MS-CHAPv2 lives in an ASCII world. Hmmm... is an update to 2759 in any way feasible? Considering its deployed base that appears difficult at best. [BA] So what do we do about this? Some of the following may be needed to fix the problem: a. A document on NAI internationalization, updating RFC 4282. This would address the (IMHO incorrect) punycode encoding of the realm portion. b. A document on EAP internationalization, updating RFC 3748. This would cover the EAP-Response/Identity as well as potentially giving advice on issues such as password internationalization and internationalization of the EAP Peer-Id and Server-Ids. I didn't notice so far that 4282 allows both UTF-8 characters AND demands punycode conversion on the realm part. That adds another bit to the confusion indeed. I also think the punycode translation is wrong at this place. It should rather be done by an application if it needs to look up the realm in DNS by the time it is looked up in DNS, not before that on the wire. Especially since 4282 does allow UTF-8 encoding to be transported literally. NAIs can also be used outside of EAP (right?), so the issue of fixing punycode in NAI is independent of fixing the character encoding in EAP. Fixing EAP character encoding for proper internationalisation is also needed IMHO, for all the reasons outlined in the thread before. So, in short, both a) and b) seem necessary to me. UTF-8 endcoded Grüße, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and UTF-8
Hi, RFC 3748 Section 5.1 allows additional data to be transmitted after the NUL in an Identity Request. This could perhaps be leveraged to send a string such as UTF-8, which could indicate to the supplicant that the server is requesting UTF-8 encoding. Hmm... In 802.1X, the EAP-Request/Identity is sent by the authenticator, which, in a scenario with multiple home authentication servers and realms, does not necessarily know which home server expects which encoding. A negotiation would be very nice, but I doubt it can work that way in a 802.1X deployment. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and UTF-8
Hi, The alternative is for supplicants to simply start using UTF-8. It's likely a good idea, in any case. Yes, I'd be very happy if supplicants did that. Obviously some refrained from doing it so far, and I don't think there is a lot of incentive to make them change their code if we can't even rightfully claim that the current behaviour is violating the EAP RFC. A compatibility option would be for the server to look at it's list of known users, and convert them (where appropriate) to UTF-8. I start to wonder how this was supposed to work reliably anyway so far. The encoding is undefined, so even if a user db on the server side and what a client sends are in sync initially, the process could break at any time with a character-set related change in the client's OS which is not necessarily related to the supplicant. I.e. it looks to me that using non-ASCII characters in EAP-Identities so far was a question of chance. That, or simply people didn't use non-ASCII for identities. Which leads to the third option: screw non-ASCII in NAIs. Though that is probably not an overly popular approach. And RFC4282 includes it as valid explicitly. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of emu-eaptunnel-req-00, chunk 1
Hi,
This is a desirable property IMHO. It's not unusual for directories to
employ policies that limit the use of credentials if they are about to
expire. If you can't log on to the network to change your credentials so
that you can log onto the network, you have a chicken-and-egg situation.
{EAP-}MSCHAP allows this, of course, so perhaps it doesn't need to be a
property of the outer-method providing that the outer-method doesn't
preclude the option.
The section in question states that the (outer) tunnel method SHOULD
provide support for it. Your reasoning is perfectly fine for MS-CHAP in
the *inner* auth. The outer method is not supposed to interfere with the
inner method's proceeding and doesn't need to provide any special support.
The property of being able to change passwords within the payload of the
tunnel method is already expressed in section 4.5.4 when it comes to
dealing with legacy password databases in the inner auth (where it
belongs, IMHO). I'd suggest to either mention it only in there, or to
make sure in 3.1 that any such management operation is not the tunnel
method's business.
TLS is not itself a CPU intensive protocol, although some of the cipher
suites are.
Point taken. That does not make the para in the document much more
useful though IMHO.
Greetings,
Stefan
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la
Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
Tel: +352 424409 1
Fax: +352 422473
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Liaison Statement on ITU-T Recommendation X.1034
Hi, - EAP-MD5: they claim it provides mutual authentication That table has a few more flaws. EAP-MD5 -- - MD5 and Resistance to dictionary attacks. RFC3748 states No, the ITU document states Yes. - MD5 and replay protection. Ditto. EAP-TLS - - they quote RFC2716 as source, while this has been obsoleted by 5216 - 2.1.4 of RFC5216 explains how to achieve privacy, while the table in X.1034 states No Luckily, the table is apparently not part of the recommendation, but an informational appendix only. I have no experience with SRP and AKA to say more about these. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Review of draft-clancy-emu-chbind-02.txt
Hi, o Service Provider Network: An EAP-enabled mobile phone provider operating along a geo-political boundary could boost their cell towers' transmission power and advertise the network identity of the neighboring country's indigenous provider. This would cause unknowing handsets to associate with an unintended operator, and consequently be subject to high roaming fees without realizing they had roamed off their home provider's network. [BA] This seems like a good example. My understanding is that power boosting actually does occur. It might be worthwhile to consider adding an Appendix to talk about how channel bindings might address this or other potential examples. I second that, as I'm living close to a geo-political border and am *constantly* in the foreign network. It can easily happen even without boosting when the base stations are placed in a challenging geological shape (hill regions...). Well at least the GSM network ID is not faked in my case and I can see that I'm roaming on the handset. Also apart from that, the problem of facing the same network ID in a roam/non-roam scenario is popping in our WiFi deployment eduroam in real life. We advertise the same SSID globally to ease roaming. Meanwhile, some hotspots are so close to one another that a user may not notice if he's being logged into his home network (a university) or a roaming network nearby (the pub next door to that university). Having a negotation mechanism within EAP to be able to tell supplicants if they are in a roaming state or not would be very beneficial. One way to transport the single round-trip exchange is as a series of Diameter AVPs formatted and encapsulated in EAP methods per [I-D.clancy-emu-aaapay]. For each lower layer, this document defines the parameters of interest, and the appropriate Diameter AVPs for transporting them. Additionally, guidance on how to perform consistency checks on those values will be provided. [BA] One potential complicating factor will be RADIUS extended attributes. These will be encoded as Diameter vendor-specific AVPs, potentially with grouping. It might make sense to explicitly state that attributes useful for Channel Bindings should probably be allocated in the standard RADIUS space, to avoid this potential gotcha. It also might be useful to state how the comparison is to be done (e.g. ignore Diameter AVP 'M' bit). Depending on the amount of AVPs in the EAP round-trip, also EAP methods with currently little amounts of data to be transferred from supplicant to RADIUS server might become too large to fit into a UDP datagram and the pain of fragmentation as we already see it with EAP-TLS might become relevant. That appears to be unavoidable though (and can be mitigated by using a reliable transport). Additionally, an interface is necessary for populating the EAP server database with the appropriate parameters. In the enterprise case, when a NAS is provisioned, information about what it should be advertising to peers needs to be entered into the database. In the service provider case, there should be a mechanism for entering contractual information about roaming partners. [BA] Do we really expect operators to enter in all potential AAA parameters into the database? This seems like a substantial operational burden. Instead, I'd suggest that for some parameters, auto-registration might be helpful -- allowing the database to be populated based on the AAA attributes first obtained from the NAS when it is provisioned. While this trusts that the NAS isn't sent to the operator in a compromised state, but only becomes compromised later, it would ease the operational burden. I second that demanding a full set to be entered is operationally very difficult, if not prohibitive, in larger environments. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Consensus call on EAP-GPSK key lengths
Hi, Please respond FOR or AGAINST making the input and output lengths independent. This consensus call will last until August 19. I vote FOR independence. Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
