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

From: Stefan Winter <[email-masked]>
Date: Sun, 02 Mar 2014 16:25:24 +0100

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.

> 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 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).

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...

Greetings,

Stefan Winter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 03 Mar 2014 08:46:47 +0100

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.
>>
>> 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.
>>
>> 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.

> 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.

> 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.

> (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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Mar 2014 04:41:49 -0500

I don't support adding phony state attributes in the first packet of
fragmentation.
Presence or absence of state should be an indicator to everyone involved
(proxies, end servers) that this is an ongoing conversation.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 03 Mar 2014 09:50:22 +0000

An alternative would be to send an EAP-Message containing a NAK
containing no data.

  i.e. 0x02000403

  It's EAP-Message, which satisfies the existing requirements.  An
intermediate proxy shouldn't really be snooping on the EAP conversation,
so it shouldn't care about the contents of EAP-Message.

  Anyone else looking at the contents should be clear that it's not a
working EAP session.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 03 Mar 2014 11:01:32 +0100

>    Anyone else looking at the contents should be clear that it's not a

What would be wrong with using EAP-Start message (i.e. empty EAP-Message 
attribute).

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Mar 2014 05:06:29 -0500

Is anyone proposing we solve this problem?
That is, is anyone unhappy with 04?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 03 Mar 2014 18:12:14 +0000

> What would be wrong with using EAP-Start message (i.e. empty EAP-Message

  Nothing, really.  Just people who look at it but shouldn't be looking
at it.. .might get confused.

  Alan DeKok.

---

From: <[email-masked]>
Date: Tue, 4 Mar 2014 15:22:31 +0000

I repeat my comment raised during the meeting. 

RFC6929 (Std) allocates the first bit after the Extended-Type field to the (M)ore and the rest (7-bit) is put as reserved.
But there is nothing about how to allocate the remaining reserved bits.

This draft allocates the second bit to (T)runcation.

The question is simple: how do we ensure that another draft will not allocate the same 2nd bit to another feature? It would mean that the same Long-extended-type attribute would have two possible interpretations/process...

Are we only relying on living memories? :)
Maybe we don't care because it is an experimental document... or maybe this doc will update the RFC6929 to indicate that the 2nd bit is used for "T".

It is not an issue with the current draft. Just an administrative issue.

Regards,

Lionel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 04 Mar 2014 15:33:41 +0000

> The question is simple: how do we ensure that another draft will not allocate the same 2nd bit to another feature? It would mean that the same Long-extended-type attribute would have two possible i…

  I think we're safe with manual tracking.  I don't see any other draft
allocating the same bit.

> Are we only relying on living memories? :)

  The documents are available on a public web page as part of the RFC
process.

> Maybe we don't care because it is an experimental document... or maybe this doc will update the RFC6929 to indicate that the 2nd bit is used for "T".

  We can't have an experimental draft update a standards track document.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Mar 2014 09:34:49 -0800

This is the reason why the fragmentation draft will have an update
relationship on RFC 6929.   This sys that anybody looking at 6929 needs to
look at this draft to see what was updated.

> -----Original Message-----
> From: radext [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, March 04, 2014 7:23 AM
> To: Alan DeKok; Alejandro Perez Mendez
> Cc: Sam Hartman; Stefan Winter; [email-masked]
> Subject: [radext] radius-fragmentation: New flag T field for the Long
> Extended Type
> 
> RFC6929 (Std) allocates the first bit after the Extended-Type field to the
> (M)ore and the rest (7-bit) is put as reserved.
> The question is simple: how do we ensure that another draft will not
allocate
> the same 2nd bit to another feature? It would mean that the same Long-
> extended-type attribute would have two possible interpretations/process...
> 
> Are we only relying on living memories? :) Maybe we don't care because it
is
> an experimental document... or maybe this doc will update the RFC6929 to
> indicate that the 2nd bit is used for "T".
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur,
veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes.
Les
> messages electroniques etant susceptibles d'alteration, Orange decline
toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete
> this message and its attachments.

---

From: <[email-masked]>
Date: Tue, 4 Mar 2014 17:39:14 +0000

Thank you!
I have seen that it was the case in the header of the draft.

Updates: RFC6929 (if approved)  

Cheers,

Lionel

-----Message d'origine-----
De : Jim Schaad [mailto:[email-masked]] 
Envoyé : mardi 4 mars 2014 18:35
À : MORAND Lionel IMT/OLN; 'Alan DeKok'; 'Alejandro Perez Mendez'
Cc : 'Sam Hartman'; 'Stefan Winter'; [email-masked]
Objet : RE: [radext] radius-fragmentation: New flag T field for the Long Extended Type

allocate
is
exploites
veuillez
Les
toute
delete

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Mar 2014 09:38:30 -0800

> From: radext [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, March 04, 2014 7:34 AM
> To: [email-masked]
> Cc: Sam Hartman; Stefan Winter; Alejandro Perez Mendez; [email-masked]
> Subject: Re: [radext] radius-fragmentation: New flag T field for the Long
> Extended Type
> 
> allocate the same 2nd bit to another feature? It would mean that the same
> Long-extended-type attribute would have two possible
> interpretations/process...
> 
allocating
> the same bit.
> > Maybe we don't care because it is an experimental document... or maybe
> this doc will update the RFC6929 to indicate that the 2nd bit is used for
"T".
>   We can't have an experimental draft update a standards track document.

For this type of update, I see no reason this draft cannot  update  the
standards track document.  It is not changing any significant content in
that draft.

Jim