Re: Last Call: draft-funk-eap-ttls-v0 (EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)) to Informational RFC

Jari Arkko <jari.arkko@piuha.net> Wed, 19 March 2008 22:50 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A222B3A6CF7; Wed, 19 Mar 2008 15:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.386
X-Spam-Level:
X-Spam-Status: No, score=-100.386 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GthvhgYtu+Hw; Wed, 19 Mar 2008 15:50:47 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5A23A6EDB; Wed, 19 Mar 2008 15:50:45 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2969A3A6D99; Wed, 19 Mar 2008 15:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYTOgf9t10Ii; Wed, 19 Mar 2008 15:50:43 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 03A913A6D88; Wed, 19 Mar 2008 15:50:42 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4F44119875F; Thu, 20 Mar 2008 00:48:24 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E6B4219866E; Thu, 20 Mar 2008 00:48:23 +0200 (EET)
Message-ID: <47E19837.3060508@piuha.net>
Date: Thu, 20 Mar 2008 00:48:23 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: draft-funk-eap-ttls-v0 (EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)) to Informational RFC
References: <20080319221403.66CF03A6A62@core3.amsl.com>
In-Reply-To: <20080319221403.66CF03A6A62@core3.amsl.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: emu@ietf.org, eap-WG <eap@frascone.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) '
>    <draft-funk-eap-ttls-v0-04.txt> as an Informational RFC
>
> 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@ietf.org mailing lists by 2008-04-16. Exceptionally, 
> comments may be sent to iesg@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>   

Some additional background is needed here.

This document is being AD sponsored to Informational RFC. The document
describes what the widely deployed EAP TTLS protocol does. The
specification should be as accurate representation of the deployed
implementations as possible, including its limitations, which in some
cases are rather severe (lack of crypto binding etc). Last call comments
are solicited in particular from people who have implemented this and
can spot deviations between implementations and this spec. Comments are
also solicited from the security community in an effort to be as
accurate about the security properties of this method as possible.

We are publishing this in an effort to document existing EAP protocol
mechanisms. Previously, a large fraction of all deployed EAP usage ran
on vendor-specific, undocumented, or poor/outdated/unstable
specifications. Many such methods were introduced prior to the adoption
of the new IANA rules in RFC 3748. At this time, high-quality standards
track specifications for EAP methods are also expected to come out of
the EMU WG. It is my belief that the EAP user community will benefit
from the documentation of both of these categories of methods.

Jari

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf