It seems the two extra bytes indicate an additional type and length?
F9 = 249
84 = 132 = SAML-AAA-Assertion in dictionary.ukerna
249 being the length that the RADIUS server tried to set the string to?
Adam Bishop
JANET(UK)
On 31 Oct 2011, at 22:23, Adam Bishop wrote:
> Mystery solved.
>
> The two static bytes triggered something in the back of my mind from the RADIUS rfc - when using an attribute of type string or text, the maximum length is 253 octets, not 255.
>
> Though, I can't remember what the extra 2 bytes mean... possibly just "I AM STRING"
>
> So, terminating each attribute at 247 is the correct behaviour.
>
>
> string 1-253 octets containing binary data (values 0 through
> 255 decimal, inclusive). Strings of length zero (0)
> MUST NOT be sent; omit the entire attribute instead.
>
>
> Adam Bishop
> JANET(UK)
>
> On 31 Oct 2011, at 21:55, Rhys Smith wrote:
>
> Actually, it's turning out to be a bit slightly different than I thought.
>
> First of all - caveat emptor - I think I'm doing all of this right, but I don't normally operate at the packet level end of things, so i'm not 100% sure of this!
>
> So I'm running tcpdump on the freeradius server as it sends the radius packets out, and on the service's server as it receives them, also looking at the output of radiusd -X on the radius IdP to see what it thinks it's about to send, and the output of gss-server on the service to see what is received on the other end of our code.
>
> Anything <=247 characters goes through fine. Anything > 247 characters disappears (as we knew).
>
> However, our assumption that it was not traversing the network okay or disappearing in our code was wrong, it actually seems to disappear between what the output of radiusd -X shows (which shows me the SAML-AAA-Assertion split into chunks but with nothing missing) and the packets actually leaving the freeradius IdP box as I see in tcpdump, where anything beyond character 247 disappears. So the other end is receiving what was sent as would be expected.
>
> In the radius packet trace leaving I'm seeing:
> * an AVP of length 255, as you'd expect.
> -> AVP: l=255 t=Vendor-Specific(26) v=UKERNA (United Kingdom Education and Research Networking(25622)
>
> In the AVP are always 6 bytes (1a ff 00 00 64 16) at the start (Identifying the attribute?), followed by a VSA of length 249
> -> VSA: l=249 t=Unknown-Attribute(132): 3c3f786d6c2076657273696f6e3d27312e302720656e636f…
>
> The VSA seems to always have 2 bytes (84 f9) at the start (framing bytes or something?), leaving room for 247 bytes (chars) of content.
>
> Reducing the size of the chunks to less than 247 gives a corresponding reduction in the above (e.g. split every 237 characters gives an AVP l=245 containing VSA l=239).
>
> So maybe someone more familiar with freeradius and/or RADIUS can explain this…?
>
> Anyway, for now, simply making SAML fragments split at 247 characters seems to be the easiest way forward :-). Would be nice to know what's happening though, and whether this is expected behaviour or not...
>
> R.
> --
> Dr Rhys Smith: Identity, Access, and Middleware Specialist
> Cardiff University & JANET(UK)
>
> email: [log in to unmask]<mailto:[log in to unmask]> / [log in to unmask]<mailto:[log in to unmask]>
> GPG: 0xDE2F024C
>
> On 31 Oct 2011, at 13:12, Sam Hartman wrote:
>
> Yeah, the 254 vs 253 thing is annoying and we also ran into that in
> Moonshot's mech_eap. However this is something different and probably a
> bug in our code (assuming things travel through the network OK, which I
> believe Rhys is confirming).
>
> --Sam
>
>
>
> JANET(UK) is a trading name of The JNT Association, a company limited
> by guarantee which is registered in England under No. 2881024
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
|