http://blog.gmane.org/gmane.ietf.emu hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.emu/2035 <pre>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 </pre> Stefan Winter 2013-04-29T14:13:08 http://comments.gmane.org/gmane.ietf.emu/2034 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:02:14 http://comments.gmane.org/gmane.ietf.emu/2033 <pre>We recently submitted a new revision of draft-ietf-emu-eap-tunnel-method-06 that we believe resolves the comments received during Working group last call. We believe it is ready to go to the IESG. Thanks, Joe </pre> Joseph Salowey (jsalowey 2013-04-02T21:25:30 http://comments.gmane.org/gmane.ietf.emu/2032 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-06.txt Pages : 105 Date : 2013-03-22 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-e</pre> internet-drafts< at >ietf.org 2013-03-22T18:18:03 http://comments.gmane.org/gmane.ietf.emu/2031 <pre>This is an announcement for working group last call for draft-ietf-emu-crypto-bind-03. Please send your comments to the EMU mailing list by April 12, 2013. The tools URL for the daft is: http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-03 </pre> Joseph Salowey (jsalowey 2013-03-18T17:01:20 http://comments.gmane.org/gmane.ietf.emu/2030 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Mutual Cryptographic Binding Author(s) : Sam Hartman Margaret Wasserman Dacheng Zhang Filename : draft-ietf-emu-crypto-bind-03.txt Pages : 25 Date : 2013-03-14 Abstract: As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middl</pre> internet-drafts< at >ietf.org 2013-03-14T15:05:26 http://comments.gmane.org/gmane.ietf.emu/2028 <pre> Can the presenters please send slides to the chairs? Thanks. </pre> Alan DeKok 2013-03-10T19:12:43 http://comments.gmane.org/gmane.ietf.emu/2023 <pre>I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 - Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? Question #2 - Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form "&lt; at &gt;realm" to be placed in a server certificate to define that it is the EAP server for the realm. This does </pre> Jim Schaad 2013-03-05T02:13:06 http://comments.gmane.org/gmane.ietf.emu/2014 <pre> WGLC in same if the server the peer be it to adds a see methods #2 tunnel over CA. will be sufficiently not is a peer into the the is an this could present. a types acknowledge. </pre> Jim Schaad 2013-02-28T03:29:02 http://comments.gmane.org/gmane.ietf.emu/2013 <pre> 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. </pre> Sam Hartman 2013-02-25T21:36:02 http://comments.gmane.org/gmane.ietf.emu/2012 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : EAP Mutual Cryptographic Binding Author(s) : Sam Hartman Margaret Wasserman Dacheng Zhang Filename : draft-ietf-emu-crypto-bind-02.txt Pages : 25 Date : 2013-02-25 Abstract: As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middl</pre> internet-drafts< at >ietf.org 2013-02-25T15:14:44 http://comments.gmane.org/gmane.ietf.emu/2009 <pre> 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 impl</pre> Sam Hartman 2013-02-24T01:46:46 http://comments.gmane.org/gmane.ietf.emu/2007 <pre> So, the current crypto binding draft has empty sections for a survey of tunnel methods and a survey of inner methods. Does anyone have an idea what was going to go in those sections? I'm guessing I put those section headers there, but I cannot remember what I was going to survey for. If there's something we want to collect about methods I'm happy to do it. Otherwise, though, I'd prefer to drop the sections. </pre> Sam Hartman 2013-02-22T23:19:16 http://comments.gmane.org/gmane.ietf.emu/2005 <pre>The EMU meeting is scheduled for Tuesday March 12, 10:30 - 11:30 Please let the chairs know if you have Items for the agenda. Thanks, Joe </pre> Joseph Salowey (jsalowey 2013-02-22T18:57:38 http://comments.gmane.org/gmane.ietf.emu/2004 <pre> role looked RFC2119 natural clarified. Should TLV or answer I 4.2.1 scarce (section essentially is to the could be than a referenced </pre> Jim Schaad 2013-02-21T23:23:36 http://comments.gmane.org/gmane.ietf.emu/2003 <pre> 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 DeKok. </pre> Alan DeKok 2013-02-12T20:53:35 http://comments.gmane.org/gmane.ietf.emu/1996 <pre>I just wanted to make sure that the mail list had at least the basics of what I mentioned in the f2f today 1. The document does not appear to have an indicator that the EMSK was or was not used to generate a confirmation value. I have not done a final check that this is true but I did try and find it a couple of times 2. The flags on the outer packet need to be defined a bit better. a) is the S bit set only on the first fragment of the first message or on all fragments of the first message b) are the two length bits set only on the first message in a fragment sequence or can they be on any of the messages in a fragment sequence (but the values must then be the same in all fragment messages) c) Can the O bit be set only in the first piece of a fragment, or could it be in the last one without being in any previous one d) Should the L bit never be set on a non-fragmented message since it is redundant 3. There needs to be a signaling mechanism when running inner EAP messages to say that </pre> Jim Schaad 2012-11-08T00:48:14 http://comments.gmane.org/gmane.ietf.emu/1995 <pre> Message forwarded from the WG-chairs list. _______________________________________________ Emu mailing list Emu&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/emu </pre> Alan DeKok 2012-11-01T13:07:39 http://comments.gmane.org/gmane.ietf.emu/1993 <pre>EMU Meeting at IETF 85 WEDNESDAY, November 7, 2012 - 1440-1540 ------------------------------------------------- 1. Note Well, agenda, note takers (5 Min) 2. Tunnel Method (30 min) - Cam-Winget http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 3. Mutual Crypto Binding (10 Min) - Hartman http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-00 </pre> Joseph Salowey (jsalowey 2012-10-23T18:46:26 http://comments.gmane.org/gmane.ietf.emu/1988 <pre>EMU is scheduled to meet Wednesday, November 7, 1440-1540. I expect we will spend most of the meeting working on any remaining issues for TEAP and mutual crypto binding work. Please let the chairs know if there are additional topics to discuss. Thanks, Joe </pre> Joseph Salowey (jsalowey 2012-10-15T15:58:37 http://comments.gmane.org/gmane.ietf.emu/1960 <pre>I found two that I forgot to include in the last message 1. When exporting the user-id, does there need to be a way to distinguish at export time between the different types of ids that are authenticated by the server? This does not seem to be an issue on the peer as it will only do mutual authentication to servers and thus only have server ids, however a server may authenticate to different types of identities on the peer. At the moment we have identified user and machines as types of entities to be identified, I suppose in the future we could add Ewoks as a different type of entity that could be identified. However the export function of user-ids does not make a distinction between the different types of authenticated entities. Should it do so or should it just export user authentications? 2. Is there a map of TLVs that should not be sent together or need to be processed in a specific order? The case I was looking at was for the Identity TLV and the EAP TLV. Is there a difference in how a peer sh</pre> Jim Schaad 2012-10-01T17:10:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.emu