[radext] Issue with draft-ietf-radext-radius-fragmentation, pre-authorization phase and authentication attributes.

Alejandro Perez Mendez <alex@um.es> Fri, 28 February 2014 12:10 UTC

Return-Path: <alex@um.es>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B31A0057 for <radext@ietfa.amsl.com>; Fri, 28 Feb 2014 04:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5JA5cnqrs3yY for <radext@ietfa.amsl.com>; Fri, 28 Feb 2014 04:10:40 -0800 (PST)
Received: from xenon24.um.es (xenon24.um.es []) by ietfa.amsl.com (Postfix) with ESMTP id B0E871A0221 for <radext@ietf.org>; Fri, 28 Feb 2014 04:10:39 -0800 (PST)
Received: from localhost (localhost []) by xenon24.um.es (Postfix) with ESMTP id E19B5EC57 for <radext@ietf.org>; Fri, 28 Feb 2014 13:10:36 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([]) by localhost (xenon24.um.es []) (amavisd-new, port 10024) with LMTP id 4bzJ-Y7VJsDP for <radext@ietf.org>; Fri, 28 Feb 2014 13:10:36 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id A33BDEB87 for <radext@ietf.org>; Fri, 28 Feb 2014 13:10:36 +0100 (CET)
Message-ID: <53107CBB.3020407@um.es>
Date: Fri, 28 Feb 2014 13:10:35 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------030105030604030400090009"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/sG-y0nefGKPp4p4-9Oj6sVQdi08
Subject: [radext] Issue with draft-ietf-radext-radius-fragmentation, pre-authorization phase and authentication attributes.
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 12:10:43 -0000

Dear all,

We have found an issue that might affect to the pre-authorization phase
of this specification. In particular, RFC 2865 specifies that :

    An Access-Request MUST contain either a User-Password or a CHAP-
    Password or a State. An Access-Request MUST NOT contain both a
    User-Password and a CHAP-Password. If future extensions allow other
    kinds of authentication information to be conveyed, the attribute
    for that can be used in an Access-Request instead of User-Password
    or CHAP-Password.

However, in draft-ietf-radext-radius-fragmentation, the first chunk of
the pre-authorization phase may not contain any of these attributes, as
it would depend on the type of the attributes being transported, as well
as the specific distribution of these attributes along the different
chunks. This issue would be circumscribed to this first chunk, as the
rest will contain a State attribute, accepted by RFC 2865.

draft-ietf-radext-radius-fragmentation already states that compliant
servers will postpone all authorization and authentication handling
until all of the chunks have been received. We have added (for version
04, that will be uploaded next Monday when the submission process
reopen) some lines clarifying that this postponement also includes
disabling the verification of the inclusion of authentication attributes
until the original large packet has been rebuilt. Hence, any server
implementing draft-ietf-radext-radius-fragmentation would not fail if
the first chunk does not contain any authentication attribute.

We expect that proxies will not drop these packets either, as otherwise
they will be precluding any future extension foreseen by RFC 2865.

In our opinion, these lines are sufficient to overcome RFC2865's
restriction. However, if the WG members think they are not, then we
might need to include some kind of phony authentication attribute on
this first chunk, just to make it compliant with what it would be
generally expected. For example, an empty EAP-Message attribute (called
EAP-Start in RFC 3579), or a phony CHAP-Password.