Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03

Folks on the EMU list may want to comment on this work as well.  

Cheers,

Joe

Begin forwarded message:

> From: Jouni Korhonen <jouni.nospam <at> gmail.com>
> Subject: [radext] WGLC #1 for draft-ietf-radext-nai-03
> Date: June 3, 2013 9:42:45 PM PDT
> To: "radext <at> ietf.org" <radext <at> ietf.org>
> Cc: "radext-chairs <at> tools.ietf.org" <radext-chairs <at> tools.ietf.org>
> 
> Folks,
> 
> This email starts a two week WGLC for draft-ietf-radext-nai-03. The WGLC end
> 18th June 2013 EOB (EEST). We require minimum three reasonable reviews. Post
> your comments and concerns to the mailing list and also enter your issues you
> want to be _addressed/resolved_ into the issue tracker.
> 
> 
> - Jouni & Mauricio
> _______________________________________________
> radext mailing list
> radext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/radext

AD review of draft-ietf-emu-crypto-bind-03.txt

I've got no problem initiating an IETF LC on this document, but I do 
have some nits that need to be fixed before I'll add it to the IESG 
telechat.  Authors please let me know whether you'd like me to initiate 
the IETF LC now or whether you'd like to submit a revised ID.  I only do 
this because these are minor but will no doubt be called out by somebody 
on the IESG as a comment and I rather avoid that.

0) abstract: r/[RFC 3748]/RFC 3748

RFC editor would remove the references from the abstract so it's better 
to do it now or have it pointed out by the gen-art reviewer.

1) move keys words to section 1.1 or make a new section 2.

RFC editor will move it so it's better to do it now or else have it 
pointed out by the gen-art reviewer.

2) s1: r/The Extensible Authentication Protocol [RFC3748]
         /The Extensible Authentication Protocol (EAP) [RFC3748]

Need to re-expand EAP in s1.

3) s3.2.2: delete:Please view in a fixed-width font such as Courier.

4) s3.2.2: The formatting here seems a little off:

  An attacker can convert an inner authentication using an EAP method
  to a inner authentication that does not use EAP in some cases.  This
  may avoid cryptographic binding.

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

From: The IESG <iesg-secretary <at> ietf.org>
Subject: [abfab] Last Call: <draft-ietf-abfab-eapapplicability-03.txt> (Update to the EAP Applicability Statement for ABFAB) to Proposed Standard
Date: 2013-06-03 13:18:21 GMT

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
ietf <at> ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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")

Biggest Fake Conference in Computer Science

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 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 

draft-ietf-emu-eap-tunnel-method-06

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

I-D Action: draft-ietf-emu-eap-tunnel-method-06.txt

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-emu-eap-tunnel-method

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tunnel-method-06

Working Group Last Call for draft-ietf-emu-crypto-bind-03

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

I-D Action: draft-ietf-emu-crypto-bind-03.txt

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-middle attacks and recommends mutual cryptographic binding, a new
   form of cryptographic binding that protects both peer and server
   along with other mitigations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-03

Slides

  Can the presenters please send slides to the chairs?

  Thanks.

Re: Last call comments on emu-eap-tunnel-method-05

On Feb 21, 2013, at 1:10 PM, Jim Schaad <jimsch <at> augustcellars.com> wrote:

> I have no comments that I would consider to be blocking.  There are couple
> of issues that should be considered to be dealt with in the last call.
> 
> Jim
> 
> 
> 
> 1.  Lower case must/may in the document.  There are disputes about the role
> of a lower case must in a document.  Some people consider it to be an RFC
> 2119 usage and some people don't.  If it is then these all need to be looked
> at, if it doesn't then I would suggest putting in text as part of the
> RFC2119 boiler plate to say that lower case versions of these words have
> their natural language meaning.
> 

[Joe]  Thanks,  well look at this and try to make the usage consistent with 2119 and move other usages to
different words

> 2.  I am not completely clear on this, but don't know if it needs to be
> clarified.
> Server and client rune one inner EAP method.
> Server sends Crypto-Binding TLV and Result TLV
> Client sends Crypto-Binding TLV, Request-Action TLV [Negotiate EAP]
> Server sends EAP-Payload [EAP start method]
> Does the server also needs to send an Intermediate-Result TLV per section
> 3.3.1?
> ---- Note - in section 3.3.3 - it would appear that there is a "may"