Date: Fri, 30 Jan 2009 09:41:50 +0100 From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de> To: "Muggeridge, Matt" <Matt.Muggeridge@hp.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Yann WANWANSCAPPEL <yann.wanwanscappel@free.fr> Subject: Re: SCTP, possible bug in peer authentication key Message-ID: <0D5E2F07-ABE5-46D8-8060-570E4B2AFD71@lurchi.franken.de> In-Reply-To: <DAE8EEF9700DC84CB97414D6CF6FCA713E79BEC1EF@GVW1160EXB.americas.hpqcorp.net> References: <4980B747.7070400@free.fr> <A36412A3-53FA-4738-A875-8DFB78C8FE58@lurchi.franken.de> <DAE8EEF9700DC84CB97414D6CF6FCA713E79BEC1EF@GVW1160EXB.americas.hpqcorp.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Matt,
Peter Lei (who wrote the AUTH code) already fixed that in Randalls CVS =20=
server.
So it will show up when Randall syncs the repositories next time.
Thank you for pointing that out. I missed that...
Best regards
Michael
On Jan 30, 2009, at 2:37 AM, Muggeridge, Matt wrote:
>> I think I found a bug in the SCTP authentication code, in
>> sctp_load_addresses_from_init() in sctp_pcb.c
>
> I noticed the same calculation appears in =20
> sctp_auth.c:sctp_auth_get_cookie_params(). Does this fix also need =20=
> to be applied there?
>
> Cheers,
> Matt.
>
> -----Original Message-----
> From: Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de]
> Sent: Thursday, 29 January 2009 6:23 PM
> To: Yann WANWANSCAPPEL
> Cc: freebsd-net@freebsd.org
> Subject: Re: SCTP, possible bug in peer authentication key
>
> Hi Yann,
>
> very good catch! You are right.
>
> I have committed your patch to Randalls repository, so it will show =20=
> up in the FreeBSD sources soon (next time he syncs them)...
>
> Best regards
> Michael
>
> On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote:
>
>> Hi all,
>>
>> I think I found a bug in the SCTP authentication code, in
>> sctp_load_addresses_from_init() in sctp_pcb.c
>>
>> keylen =3D sizeof(*p_random) + random_len + sizeof(*chunks) + =20
>> num_chunks
>> +
>> sizeof(*hmacs) + hmacs_len;
>>
>> The keylen calculation assumes the Chunk List Parameter (CHUNKS)
>> vl-param was present in the received INIT packet, which can be false
>> if peer SCTP does not require any chunk to be authenticated (this
>> typically occurs if peer does not support ASCONF).
>>
>>> =46rom RFC 4895, 6.1
>>
>> * An SCTP endpoint has a list of chunks it only accepts if they are
>> * received in an authenticated way. This list is included in the =20
>> INIT
>> * and INIT-ACK, and MAY be omitted if it is empty. Since this list
>> * does not change during the lifetime of the SCTP endpoint there is =20=
>> no
>> * problem in case of INIT collision.
>>
>> This case is properly handled later in the build of the key
>>
>> /* append in the AUTH chunks */
>> if (chunks !=3D NULL) {
>> .....
>> }
>>
>> I think the calculated keylen should be something like this :
>>
>> keylen =3D sizeof(*p_random) + random_len + sizeof(*hmacs) + =
hmacs_len;
>>
>> if (chunks !=3D NULL) {
>> keylen +=3D sizeof(*chunks) + num_chunks }
>>
>> This problem results in authenticated packets sent from peer SCTP to
>> be discarded.
>>
>> The problem does not occurs if peer SCTP is modified to send an empty
>> Chunk List Parameter, (eg num_chunks =3D 0 in the decoding).
>>
>> Br,
>> Yann
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-=20
>> unsubscribe@freebsd.org"
>>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D5E2F07-ABE5-46D8-8060-570E4B2AFD71>