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

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.

Regards,
Alejandro

>
> Greetings,
>
> Stefan Winter
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext