JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for MOONSHOT-COMMUNITY Archives


MOONSHOT-COMMUNITY Archives

MOONSHOT-COMMUNITY Archives


MOONSHOT-COMMUNITY@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MOONSHOT-COMMUNITY Home

MOONSHOT-COMMUNITY Home

MOONSHOT-COMMUNITY  October 2011

MOONSHOT-COMMUNITY October 2011

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Problem in moonshot parsing of SAML-AAA-Assertion?

From:

Alan Buxey <[log in to unmask]>

Reply-To:

Moonshot community list <[log in to unmask]>, Alan Buxey <[log in to unmask]>

Date:

Mon, 31 Oct 2011 23:18:44 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (42 lines)

Hi,

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

as Adam has said, you've got to account for the TLV format. however, with VSA, you have the over head
of the Vendor-Specific type.... type 26.

so, from memory, you have the standard  type, length, then vendor ID, then string... but
the string itself is still set up with Type, Length and Attribute specific data (this is
where your SAML goes).

the packet is 255 bytes...then you need to take away all this stuff. 

the first stuff takes 6 bytes off, (T(1), L(1), VID(4)), then the
String itself takes another 2 (Vendor type(1) and vendor length(1)) 

ta-da! 255 bytes becomes 247

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

1a = 26  (VSA)
ff = 255 (fully loaded packet)
00006416 = 25622 (the number of UKERNA vendor)


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

84 = 132 (type attribute)
f9 = 149 (length of packet)

have you not got the type 132 attribute in your dictionary file?


alan

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager