Subject: [radext] Comments on draft-perez-radext-radius-fragmentation-04

From: "Jim Schaad" <[email-masked]>
Date: Thu, 24 Jan 2013 16:56:29 -0800

First, I would like the chairs to issue an adoption call on this document so
we can formally work on it.

Comments on the draft itself.

1.  I just did a count on the number attributes in the example for
Access-Request-1 and came up with a count of 9.  This exceeds the posited
maximum length of 8 that the example is using as a limitation.

2.  In section 5.1 - although this is going to be unusual behavior, a proxy
could remove Proxy-State attributes and keep them for later re-insertion.  I
can imagine that this behavior, while legal, could cause all sorts of
problems on a packet coming back because the SA could end up putting too
many bytes in the packet.  Does this need to be documented?

3.  In section 5.1 - Should there be some suggestions about doing retries
for chucked objects based on a timeout in the case of a proxy dropping it?

4.  In section 5.3 -- Alan - we had several discussions in Atlanta about the
interactions of a SAML authorization query combining with an EAP message.  I
think that we finally decided that since we could fragment the first
response there were no big issues involved any more.  Is my memory still
correct on this question?

5.  In section 5.3 - I am not sure why there is a requirement that these
attributes be in the same fragmentation packet.  The server SHOULD NOT start
processing the contents of the sent packet until such a time as entirety of
the full packet has been received, so unless a proxy is going to operate on
these attributes I don't see the point of this.

6. In section 5.3 - I think you need to make it explicit that for
Message-Authenticator, it is the fragment message that will be authenticated
not the entire unfragmented message.

7.  In section 5.4 - You need to document what happens with the ID attribute
as well.  (Always last?)

8.  In section 6.1 - It must not be in Access-Reject packets as well.
Should that be documented?  (also s/MUST not/MUST NOT/)

9.  In section 6.2 - see previous comments

10.  In section 6.3 - the table appears to be wrong.  I think the that
Proxy-State-Len should be 0 under the Acc column.

11.  In Section 8 - I think there is a potential security consideration that
may need to be added.  As the system is currently defined, if the
Message-Authenticator attribute is in the original message, it is not made a
requirement of all the fragments in the system.  This means that only a
subset of the original message will be authenticated.  This is a definite
security change.

12.  In section 9 - No IANA actions?  What about the required registrations?

Spelling errors

s/Acess-Request-2/Access-Request-2/
s/size of he RADIUS/size of the RADIUS/
s/should they cannot add/should they be unable to add/
s/how many space/how much space/

jim

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 25 Jan 2013 10:09:14 +0100

Hello Jim,

thanks for your valuable comments, let me try to answer to some of them 
inline.

> maximum length of 8 that the example is using as a limitation.

You counted the ID field, which is represented as an attribute for 
simplicity, though it is not. Prior describing the example it is said that

    The Identifier field is denoted as IDX, even though it is
        not an attribute.

I could either change the notation, add a better explanatory paragraph 
or just count it as an attribute for sake of simplicity again and say 
the limit is 9 attributes instead of 8.

> many bytes in the packet.  Does this need to be documented?

The main problem with RADIUS proxies is that they can do whatever they 
want, and it will  not be noticed until its maybe too late. They could 
also remove More-Data-Pending attributes, or the Proxy-State-Len for 
example. They could even re-arrange attributes, or modify their values, 
messing up the entire conversation. But that's not what they are 
expected to do.

Said that, I see the "CHUNK size calculation" mechanism as a best effort 
trade-off, where it improves current solutions (which are none) to 
adjust packet size to the actual limit taking into account proxies 
inclusions.

A worried AS/NAS could lower the guessed value by for example 200-300KB, 
just to make sure that these sort of things are avoided.

> for chucked objects based on a timeout in the case of a proxy dropping it?

Retry policy should be the same as done with non-fragmented packets. The 
NAS will retry a request if no reply arrives in a reasonable time, no 
matter whether it is a "fragmentation" reply or a "standard" reply. 
After a number of retransmissions, the NAS will stop trying, and assume 
the conversation is over. Note that no processing have been performed on 
any side until the whole packet is received (apart of storing the 
received data). Thus, there is no need for a special roll-back mechanism.

> correct on this question?

There's still the situation with SAML queries/requests (or other 
authorization type), which may be larger than the maximum size (though 
not much likely, I think). If a SAML query is required by the AS to 
determine if SAML response must sent or not in the Access-Accept packet, 
it must be definitively sent in an Access-Request packet by the RP, 
along with the  EAP-Message attributes. You would need to perform 
fragmentation if it is too big (note that EAP request may be already 
quite large, so it is not so unlikely).

Of course, another option is to not sending any SAML response data in 
the Access-Accept packet, but some kind notification to the RP in order 
to perform the whole SAML Query/SAML Response exchange *after* 
Access-Accept.

I discussed this alternative with Alan, Josh and Sam, months ago, but 
they argued that this will mandate an additional roundtrip even for RPs 
that are not interested/known nothing about SAML.bv

That's a good question. This came up to me when working with FreeRADIUS 
proxies. FreeRADIUS proxies perform that check (Message-Authenticator 
cannot be without EAP-Message), otherwise the packet is not forwarded. 
Hence, I assumed that this was somehow mandatory.

Now, reviewing RFC 3579 it says that:

    Access-Request packets including EAP-Message attribute(s) without
           a Message-Authenticator attribute SHOULD be silently discarded by
           the RADIUS server.

and:

    Access-Challenge, Access-Accept, or Access-Reject packets
           including EAP-Message attribute(s) without a Message-Authenticator
           attribute SHOULD be silently discarded by the NAS.

I couldn't find any similar text for proxies, so probably you are right 
and I is not necessary.

Anyway, I think the conclusions of the discussion about allowed 
attributes in Access-Challenge packets, specially in conjunction with 
RADIUS-EAP will be relevant here to determine if we can use together 
RADIUS-EAP and RADIUS fragmentation, since we would need to introduce 
this new attributes (More-Data-Pending and Proxy-State-Len) in Challenges.

> not the entire unfragmented message.

Probably this will depend on what happens with point 5.

> 7.  In section 5.4 - You need to document what happens with the ID attribute

I guess you mean the ID field (not an attribute, I definitively have to 
clarify that)

It will be the last one, but not sure it really matters. I think once 
the RADIUS network layer has processed the packet for retransmissions, 
fragmentation, etc, it does not matter which ID value it has, because it 
should be irrelevant for the attribute processing.

> Should that be documented?  (also s/MUST not/MUST NOT/)

Right

> Proxy-State-Len should be 0 under the Acc column.

When fragmenting an Access-Accept packet, the result transmission of 
chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first Acc 
contains the Service-Type=Additional-Authorization, and the last one the 
actual Service-Type.

This first Access-Accept will contain the Proxy-State-Len attribute to 
provide feedback to the RP about the size of Proxy-State attributes.

> subset of the original message will be authenticated.  This is a definite

Right. See points 5 and 6. Probably Message-Authenticator MUST be 
calculated over the whole packet, not only the subset.

> 12.  In section 9 - No IANA actions?  What about the required registrations?

I forgot to fill up that section :). At least we need to define 
More-Data-Pending, Proxy-State-Len and 
Service-Type=Additional-Authorization.

> s/how many space/how much space/

Best regards,
Alejandro

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 25 Jan 2013 09:18:25 -0800

From: Alejandro Perez Mendez [mailto:[email-masked]] 
Sent: Friday, January 25, 2013 1:09 AM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on draft-perez-radext-radius-fragmentation-04

Hello Jim,

Retry policy should be the same as done with non-fragmented packets. The NAS will retry a request if no reply arrives in a reasonable time, no matter whether it is a "fragmentation" reply or a "standard" reply. After a number of retransmissions, the NAS will stop trying, and assume the conversation is over. Note that no processing have been performed on any side until the whole packet is received (apart of storing the received data). Thus, there is no need for a special roll-back mechanism.

[JLS] Sorry, I should have been more clear on my comment.  Should the retry include decreasing the chunk size?

When fragmenting an Access-Accept packet, the result transmission of chunks is the following: Acc-Cha-Cha-...-Cha-Acc, where the first Acc contains the Service-Type=Additional-Authorization, and the last one the actual Service-Type. 

This first Access-Accept will contain the Proxy-State-Len attribute to provide feedback to the RP about the size of Proxy-State attributes.

[JLS]  This text from section 6.2

   This attribute MAY be present in Access-Challenge packets.  It MUST

   not be included in Access-Accept packets.

Best regards,
Alejandro

 
jim

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 25 Jan 2013 19:21:14 +0100

> *From:*Alejandro Perez Mendez [mailto:[email-masked]]
> *Sent:* Friday, January 25, 2013 1:09 AM
> *To:* Jim Schaad
> *Cc:* [email-masked]; 
> [email-masked]
> *Subject:* Re: Comments on draft-perez-radext-radius-fragmentation-04
>
> Hello Jim,
>
>   
> Retry policy should be the same as done with non-fragmented packets. 
> The NAS will retry a request if no reply arrives in a reasonable time, 
> no matter whether it is a "fragmentation" reply or a "standard" reply. 
> After a number of retransmissions, the NAS will stop trying, and 
> assume the conversation is over. Note that no processing have been 
> performed on any side until the whole packet is received (apart of 
> storing the received data). Thus, there is no need for a special 
> roll-back mechanism.
>

That could be more difficult from an implementation point of view 
(though doable, of course). In our implementation, fragmentation layer 
provides the CHUNK to the "network delivery" layer, which is the one 
performing the retransmissions. It knows nothing about fragmentation. 
But, of course, it is an implementation aspect and it can be done 
differently. RP start with a small size of CHUNK, and it should be 
conservative on the chosen size to avoid incurring in proxies dropping 
packets.

> contains the Service-Type=Additional-Authorization, and the last one 
> the actual Service-Type.
>

Oh, that text its incorrect. Thanks!

>   
>
>
> Best regards,
> Alejandro
>
>
>
>   
>   
> jim
>   
>   
>
>
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 29 Jan 2013 17:18:03 +0100

> these attributes I don't see the point of this.
I agree that maybe section 5.3 is too much restrictive taking into account the text that Alex pasted from RFC 3579

> Right. See points 5 and 6. Probably Message-Authenticator MUST be calculated over the whole packet, not only the subset.

Message-Authenticator is a hop-by-hop authenticator so I do not think it can be calculated over the whole packet. One alternative is just describing what Jim proposes by adding some note to security considerations. Other alternative might be to include Message-Authenticator attribute in all chunks from the one which requires it. For example if a RADIUS Access-Accept carries an EAP-Success and a set of attributes that do not fit in the packet, Message-Authenticator is included in that RADIUS Access-Accept and in all chunks from that message until all chunks have been sent. 

What do you think?

Best regards.
>> jim

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 29 Jan 2013 21:03:53 +0000

Hi,

> Message-Authenticator is a hop-by-hop authenticator so I do not think it can be calculated over the whole packet. One alternative is just describing what Jim proposes by adding some note to securit…

Taking into account the nature of Message-Authenticator I do not see a serious
risk in the change dealing with fragments imply, so just noting this issue in the security considerations should be enough.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx