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