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

[Alejandro Perez Mendez <[e-mail]>]

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.

Regards