In the development of a new binkp implementation (http://wiki.synchro.net/module:binkit), *we* came across a deficiency in the FTSC document: FTS-1027.

Regarding this text:

1.3 Generating and Transmitting Challenge Data
----------------------------------------------

Size and contents of challenge data are implementation-dependent,
but it SHOULD be no smaller than 8 bytes and no bigger than 64
bytes

Let it be known that the reference binkp implementation, binkd, has (apparently) only ever sent a 16 byte CRAM challenge (no more, no less) and some implementations (e.g. Internet Rex) only work (succesfully authenticate) if the received challenge is exactly 16 bytes (no more, no less).

There's no mention of a 16 byte CRAM challenge (32 hex characters) in the specification, but 16 bytes appears to be exactly what all existing implementations actually send and probably all any implementation should *ever* send if they wish to be compatible will all known existing implementations.

I just felt this should be documented, if it isn't already, by the FTSC.

Credits to Mark Lewis and Stephen Hurd.

Good ${greeting_time}, Rob!

07 Mar 2018 18:52:54, you wrote to All:

In the development of a new binkp implementation (http://wiki.synchro.net/module:binkit), *we* came across a
deficiency in the FTSC document: FTS-1027.
Regarding this text:
1.3 Generating and Transmitting Challenge Data
Size and contents of challenge data are implementation-dependent, but
it SHOULD be no smaller than 8 bytes and no bigger than 64 bytes

64 to 512 bits... that resembles one pretty good cryptographic transform.

Let it be known that the reference binkp implementation, binkd, has (apparently) only ever sent a 16 byte CRAM challenge (no more, no
less)

IIRC, that's some random data whitened by MD5 hash function. Now MD5 is proven to be unsafe(*), so the implementations should replace it with not-yet-broken crypto-safe functions like SHA2 or Skein.

and some implementations (e.g. Internet Rex) only work (succesfully authenticate) if the received challenge is exactly 16 bytes (no more,
no less).

That's a bug. Have you reported it to the developers of those mailers?

There's no mention of a 16 byte CRAM challenge (32 hex characters)
in the specification, but 16 bytes appears to be exactly what all
existing implementations actually send

8 < 16 < 64

and probably all any implementation should *ever* send if they wish
to be compatible will all known existing implementations.

What if they wish to be compatible with the published standard based on very popular reference implementation?

I just felt this should be documented, if it isn't already, by the
FTSC.

Over 80% of all IBN-capable systems use binkd, so its' behavior still is the current practice, which is exactly documented by FTSC.


(*)
Look at these two images: http://pics.rsh.ru/img/md5_collision_image2_26j2eiqr.jpg
http://pics.rsh.ru/img/md5_collision_image1_5l7k706x.jpg

Now download them and compare their sizes and MD5 sums :-)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

On 2018 Mar 08 09:09:44, you wrote to Rob Swindell:

There's no mention of a 16 byte CRAM challenge (32 hex characters)
in the specification, but 16 bytes appears to be exactly what all
existing implementations actually send

8 < 16 < 64

and probably all any implementation should *ever* send if they wish
to be compatible will all known existing implementations.

What if they wish to be compatible with the published standard based on very popular reference implementation?

you miss the point... that point being that all current implementations transmit exactly 16 bytes... no more, no less... the spec is 13 years old... common practise does not meet the spec and the spec is not documenting common practise... at least one mailer refuses to work properly with CRAM-MD5 != 16 bytes... a sample of 388450 CRAM-MD5 strings taken over three years shows ALL of them are 16 bytes (aka 32 hex characters) long... none are shorter... none are longer until recently when one implementation used the whole allowed space and found this problem...

you also say about MD5 and SHA1 being compromised... true but those are the only ones the spec lists... if there are others, where are they listed and their implementation decribed?

the posting is made here to bring the problem to the attention of the FTSC so the documentation can be reviewed and updated...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... When I get hungry, things die.
---
* Origin: (1:3634/12.73)