"ISAKMP" flaws?

[William Allen Simpson]

Florian Weimer wrote:
> Even back then, the integer encoding was considered to be a mistake.
> 
> | I concur completely. I once got so fed up with this habit that I
> | tromped around the office singing, "Every bit is sacred / Every bit
> | is great / When a bit is wasted / Phil gets quite irate."
> | 
Ah yes, Phil really _is_ like that, but then he was often working with
2400 bps satellites and ARRL links.  Did bring a smile :-)

But as another point, Phil was against having length fields in most
cases.  The transform parameters started as a list of single bytes, but
the "working group" (a misnomer) insisted on length fields.  I remember
Phil slumping down in his seat.  I convinced him we could treat them
all as 2 byte constants, since the length didn't actually vary.  ;-)


> | Consider this to be one of the prime things to correct. Personally,
> | I think that numbers should never (well, hardly ever) be smaller
> | than 32 bits.
> 
> (Jon Callas, 1997-08-08)
> 
Ah yes, a couple of years after Photuris.  And wasn't Jon the _author_
of the PGP variable length integer specification?  Hoisted on his petard?

I did use all 32-bit length fields in RADIUS.  Different environment.

And finally, the reason for the extra specification of an extension
beyond 32-bit lengths was provided by an obscure fellow by the name of
Rivest.  He argued (insisted vehemently) that security specifications
should take all possible future-proofing precautions, even though we
currently don't see the need, so that the specification is _never_
ambiguous.  (I'm paraphrasing, he was far more loquacious.)


> Variable-length integers within other fields, for example.  You can't
> avoid this phenomenon in its entirety, of course, without sacrificing
> some of the advantages of a binary encoding.
> 
There aren't any.  I could, and did.

Have you actually read all (or any) of the specifications?


> I like ISAKMP as much as the next guy, but somehow I doubt that
> simpler protocols necessarily lead to more robust software.  Sure,
> less effort is needed to implement them, but writing robust code still
> comes at an extra cost. *sigh*
> 
It's a sad day when reliability greater than provided by M$ or Netscape
is considered "extra cost".

I've always believed robust security merits the same attention to detail
that is needed in a device driver.  And I came of age in programming
communication device drivers when there was no guarantee that the
backplane would successfully carry the interrupt saying a byte had been
transferred, so you had a software timer to initiate a task to separately
query the hardware for lost characters or overruns.  And another hardware
(watch timer) interrupt just in case the software got stuck.

IBM 1800.  Alpha Micro.  HP 21MX.  IBM PC PIC.  Zilog.  Embedded process
control.  Electronically and physically noisy factory floor environments.

But it helps a lot when the specification is written hand-in-hand with
the code, so that every opportunity is taken to simplify the code.

So, where is the community to replace ISAKMP with something more robust?

Provos' Photuris code could be running on all the BSDs in a few months.
Maybe sooner, were payment involved.
-- 
William Allen Simpson
     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com