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

Alejandro Perez Mendez <> Mon, 03 March 2014 07:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D76531A078B for <>; Sun, 2 Mar 2014 23:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TyYs1GVdqU_p for <>; Sun, 2 Mar 2014 23:46:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D7801A0349 for <>; Sun, 2 Mar 2014 23:46:52 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C72B0F046; Mon, 3 Mar 2014 08:46:48 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id xoERZ9n8wVOs; Mon, 3 Mar 2014 08:46:48 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by (Postfix) with ESMTPSA id 56299EFF6; Mon, 3 Mar 2014 08:46:47 +0100 (CET)
Message-ID: <>
Date: Mon, 03 Mar 2014 08:46:47 +0100
From: Alejandro Perez Mendez <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stefan Winter <>, "" <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080408040002020103010502"
Subject: Re: [radext] Issue with draft-ietf-radext-radius-fragmentation, pre-authorization phase and authentication attributes.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Mar 2014 07:46:57 -0000

Hi Stefan,

El 02/03/14 16:25, Stefan Winter escribió:
> Hi,
>> 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.
> Which they are allowed to do. It's very arguable whether a proxy 
> should police this particular RFC constraint at all; but if it does, 
> the fragmentation process will be permanently DoSed.

That's right. But they could also drop other parts of fragmented 
packets. They could even drop parts of "regular" packets with no 
fragmentation at all. But we expect from proxies that they do proxy, and 
they do not anticipate any end-to-end verification in conversations they 
are not involved at all.

>> 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.
> I would be against phony authentication attributes - especially since 
> the frag draft is very explicitly stating that it does not do any 
> authentication at all. Omitting authentication attributes makes it 
> easy to spot that this is an authorization exchange; adding a 
> "CHAP-Password" makes it unnecessarily hard.

I agree.

> I don't understand yet what the issue is that prevents adding a phony 
> *State* though. Couldn't you just state that a first-fragment gets two 
> new attributes? One being Frag-Status; the other one being a State 
> attribute which could be a fixed 0x0 (or allow arbitrary values and 
> simply discard server-side).

When I said phony authentication attributes, I was referring to any 
attribute RADIUS considers enough to make Access-Request packet valid. 
That includes State attribute as well, as described in RFC 2865. I agree 
than CHAP-Password would be harder then a State attribute, or an 
EAP-Start attribute.

> State shouldn't be in the original Access-Request before splitting 
> (because State is used in echoing a *server's* State attribute back, 
> and has no reason for existence in the first Access-Request); so if 
> you add one together with Frag-Status, it would be the only one; so 
> there should be no ambiguity...

I think it would be a valid solution, but I'd still prefer not having to 
send any phony attribute at all.


> Greetings,
> Stefan Winter
> _______________________________________________
> radext mailing list