Re: ISAKMP flaws?
On Sat, 19 Nov 2005, Peter Gutmann wrote: - The remaining user base replaced it with on-demand access to network engineers who come in and set up their hardware and/or software for them and hand-carry the keys from one endpoint to the other. I guess that's one key management model that the designers never anticipated... I wonder what a good name for this would be, something better than the obvious sneakernet keying? Actually this is a good thing. Separation of the key distribution channel from the flow of traffic encrypted under those keys. Making key distribution require human attention/intervention. This is treating key distribution seriously, and possibly for the first time in the modern incarnation of the industry. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
bear [EMAIL PROTECTED] writes: On Sat, 19 Nov 2005, Peter Gutmann wrote: - The remaining user base replaced it with on-demand access to network engineers who come in and set up their hardware and/or software for them and hand-carry the keys from one endpoint to the other. I guess that's one key management model that the designers never anticipated... I wonder what a good name for this would be, something better than the obvious sneakernet keying? Actually this is a good thing. Unless you're the one paying someone $200/hour for it. Separation of the key distribution channel from the flow of traffic encrypted under those keys. Making key distribution require human attention/intervention. Somehow I suspect that this (making it so unworkable that you have to hand- carry configuration data from A to B) wasn't the intention of the IKE designers :-). It's not just the keying data though, it's all configuration information. One networking guy spent some time over dinner recently describing how, when he has to set up an IPsec tunnel where the endpoints aren't using completely identical hardware, he uses a hacked version of OpenSWAN with extra diagnostics enabled to see what side A is sending in the IKE handshake, then configures side B to match what A wants. Once that's done, he calls A and has a password/key read out over the phone to set up for B. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
Tero Kivinen [EMAIL PROTECTED] writes: If I understood correctly the tools they used now did generate specific hand- crafted packets having all kind of wierd error cases. When testing with the crypto protocols the problem is that you also need to do the actual crypto, key exchangement etc to be able to test things after the first packet. The two that I'm aware of (the X.509 cert data generator that found ASN.1 parser faults and the SSH hello-packet generator) both just created vaguely correct-looking PDUs that contained garbage data, so that a simple firewall check would reject 99% of the packets before they even got to the real processing. The SSH generator only sent the first packet, so it never got past the first step of the SSH handshake. I'm not sure what the ISAKMP data generator did. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 06:56 PM 11/18/2005, William Allen Simpson wrote: | tromped around the office singing, Every bit is sacred / Every bit | is great / When a bit is wasted / Phil gets quite irate. | 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? No, it was still Phil's old heavily-used petard, worked over by various other people from PGP 3.0 and PGP Inc. Jon was going for backwards compatibility in the OpenPGP specs. He may have cleaned up the specs a bit, and fixed some of the security holes from VL-integer exploits, but unfortunately OpenPGP retained almost all the old ugliness. I was always grumpy about the impossibility of doing stealth easily in the native PGP formats and the fact that the OpenPGP code fossilized it. For political reasons I'd have also liked PGP to have had an optional very simple format so you could fit it into one page of Perl or equivalent to go with the RSA in 4 lines of Perl or lisp. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
Steven M. Bellovin [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Paul Hoffman writes: Which proper programming tools would check for a logic path failure when a crafted packet includes Subpacket A that is only supposed to be there when Subpacket B is there, but the packet doesn't include Subpacket B? There are no programming tools that check for this, or for related issues: it has to be the implementer who has enough understanding of the protocol and enough time (and program space) to code against such issues. Decent test case generators. The problem is that these are extraordinarily labour-intensive to write. Admittedly they're incredibly effective in finding problems (every time someone's gone to the effort of creating one, it seems like 90% of all implementations in the target area have proven vulnerable), but that still leaves the problem of creating the things in the first place. Another issue is that all of the current ones (that I know of) test for random rather than Byzantine failures, i.e. they create large numbers of random packets and hope that one of them triggers a bug, rather than carefully crafting malicious payloads designed to cause faults. Once we get Byzantine test-case generators, I predict there'll be another round of security alerts as 90% of the products out there fail yet again. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
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 [EMAIL PROTECTED]
Re: ISAKMP flaws?
William Allen Simpson [EMAIL PROTECTED] writes: So, where is the community to replace ISAKMP with something more robust? Already happened, unfortunately it's diverged into three different branches: - VPN hardware vendors replaced it with management tunnels, typically things like single-DES-encrypted backdoors with no message integrity or message flow integrity protection and 8-character uppercase-only passwords. - Open source folks replaced it with OpenVPN. - The remaining user base replaced it with on-demand access to network engineers who come in and set up their hardware and/or software for them and hand-carry the keys from one endpoint to the other. I guess that's one key management model that the designers never anticipated... I wonder what a good name for this would be, something better than the obvious sneakernet keying? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* Peter Gutmann:
I haven't been following the IPSec mailing lists of late -- can anyone
who knows details explain what the issue is?
These bugs have been uncovered by a PROTOS-style test suite. Such test
suites can only reveal missing checks for boundary conditions, leading to
out- of-bounds array accesses and things like that. In other words, trivial
implementation errors which can be easily avoided using proper programming
tools.
I feel a need to comment on statements like this... at several times
in the past I've seen people make sweeping generalisation like this,
Everyone knows about this security weakness, this { paper | article
| security alert } isn't { novel | interesting | worth publishing },
Touché.
or some variant thereof (in this case these trivial errors are
easily avoided).
Of course, the relevance of a bug and how easily it could have been
avoided are completely different matters. I mainly wanted to point
out that there is no new cryptography involved.
What makes these statements rather unconvincing is that the majority
of all implementations out there all make these trivial
easily-avoided errors
They have chosen different trade-offs, focusing on performance,
time-to-market and things like that. It's hard enough to create an
ISAKMP implementation that works at all.
In this particular case if the problem is so trivial and easily
avoided, why does almost every implementation (according to the
security advisory) get it wrong?
How many completely independent implementations are there?
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* William Allen Simpson: Quoting Photuris: Design Criteria, LNCS, Springer-Verlag, 1999: The hallmark of successful Internet protocols is that they are relatively simple. This aids in analysis of the protocol design, improves implementation interoperability, and reduces operational considerations. Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and graduate (Spatscheck, Provos) students independently were able to complete interoperable implementations (in their spare time) in a month or so Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Paul Hoffman writes: At 11:20 AM +0100 11/17/05, Florian Weimer wrote: These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. Which proper programming tools would check for a logic path failure when a crafted packet includes Subpacket A that is only supposed to be there when Subpacket B is there, but the packet doesn't include Subpacket B? There are no programming tools that check for this, or for related issues: it has to be the implementer who has enough understanding of the protocol and enough time (and program space) to code against such issues. Decent test case generators. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
Florian Weimer wrote: Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ On the contrary: + a VERY SIMPLE variable-length integer encoding, where every number has EXACTLY ONE possible representation (unlike ASN.1 which even the spell-checker wants to replace with assinine). + similar to that of OpenPGP, the most common Open Source security software of the era, where the code could be easily reused (as it was in the initial implementation). The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. On the contrary, where are internal nested containers in the protocol? However, as most things that cross the INTER-net, the packets are encapsulated in UDP, IP, and some media frame, all of which may have their own length. That why there are copious implementation notes, saying for example: When processing datagrams containing variable size values, the length must be checked against the overall datagram length. An invalid size (too long or short) that causes a poorly coded receiver to abort could be used as a denial of service attack. I remember some observers complaining about the 17 warnings concerning comparing the variable length to the UDP length, saying it cluttered the specification. I remember some implementers cheering about the 17 warnings concerning comparing the variable length to the UDP length, saying it helped clarify the specification as they wrote the code. I defy you to find an INTER-net protocol without RTP/TCP/UDP, IP, and media framing At the time, I only had 17 years of protocol implementation experience. Another decade later, it still seems (to me) one of my better efforts. Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris was written before the existence of ISAKMP. -- 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 [EMAIL PROTECTED]
Re: ISAKMP flaws?
Florian Weimer wrote: Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ Actually, if one variable-length integer encoding is used instead of 5 other formats in all sorts of strange places, I'd say this is a good sign. Although I didn't originally like the variable-length integer I've seen used, I've come to appreciate how much simpler and thus much more secure it makes the code. The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. Containers for things are inevitable. I've found they should be encapsulated in their own protected container, so that bugs do not cross boundaries. Yes, this makes for redundancy and possibly conflict, but wasn't it said that in security programming, we should be precise in what we write out and precise in what we accept? Any conflict - reject it. iang PS: I think it was Dan Bernstein who said that, in opposition to the aphorism be gentle in what you accept? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* William Allen Simpson: Florian Weimer wrote: Photuris uses a baroque variable-length integer encoding similar to that of OpenPGP, a clear warning sign. 8-/ On the contrary: + a VERY SIMPLE variable-length integer encoding, where every number has EXACTLY ONE possible representation (unlike ASN.1 which even the spell-checker wants to replace with assinine). + similar to that of OpenPGP, the most common Open Source security software of the era, where the code could be easily reused (as it was in the initial implementation). 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. | | 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) The protocol also contains nested containers which may specify conflicting lengths. This is one common source of parser bugs. On the contrary, where are internal nested containers in the protocol? 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. Again, the ISAKMP flaws were foreseeable and avoidable. And Photuris was written before the existence of ISAKMP. 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* - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
* Perry E. Metzger: I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
Florian Weimer [EMAIL PROTECTED] writes:
* Perry E. Metzger:
I haven't been following the IPSec mailing lists of late -- can anyone
who knows details explain what the issue is?
These bugs have been uncovered by a PROTOS-style test suite. Such test
suites can only reveal missing checks for boundary conditions, leading to
out- of-bounds array accesses and things like that. In other words, trivial
implementation errors which can be easily avoided using proper programming
tools.
I feel a need to comment on statements like this... at several times in the
past I've seen people make sweeping generalisation like this, Everyone knows
about this security weakness, this { paper | article | security alert } isn't
{ novel | interesting | worth publishing }, or some variant thereof (in this
case these trivial errors are easily avoided).
What makes these statements rather unconvincing is that the majority of all
implementations out there all make these trivial easily-avoided errors (or the
majority of users aren't aware that the well-known problem in the security
alert exists, or whatever). The nicest example I've seen of this was where
the head of a standards working group explained that some obscure feature that
implementors had been getting wrong was so obvious that they'd consciously
omitted putting it in the standard because everyone just magically knew about
it.
In this particular case if the problem is so trivial and easily avoided, why
does almost every implementation (according to the security advisory) get it
wrong?
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 11:20 AM +0100 11/17/05, Florian Weimer wrote: These bugs have been uncovered by a PROTOS-style test suite. Such test suites can only reveal missing checks for boundary conditions, leading to out-of-bounds array accesses and things like that. In other words, trivial implementation errors which can be easily avoided using proper programming tools. Which proper programming tools would check for a logic path failure when a crafted packet includes Subpacket A that is only supposed to be there when Subpacket B is there, but the packet doesn't include Subpacket B? There are no programming tools that check for this, or for related issues: it has to be the implementer who has enough understanding of the protocol and enough time (and program space) to code against such issues. Throw in PKIX certificates in certificate chains, and it gets much worse. IKE is a very complicated protocol with many within-packet and within-stream dependencies. These cannot be resolved by proper programming tools unless those tools are specifically crafted for IKE. SSL/TLS probably suffers the same fate. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
Paul Hoffman wrote: At 2:29 PM -0500 11/15/05, Steven M. Bellovin wrote: I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Well, then we fully agree with each other. Look at the message formats used in the protocols they have attacked successfully so far. Humorously, security folks seem to have ignored this when designing our protocols. Later, Peter Gutmann wrote: In this particular case if the problem is so trivial and easily avoided, why does almost every implementation (according to the security advisory) get it wrong? Quoting draft-simpson-danger-isakmp-01.txt, published (after being blocked by the IETF for years) as: http://www.usenix.org/publications/login/1999-12/features/harmful.html A great many of the problematic specifications are due to the ISAKMP framework. This is not surprising, as the early drafts used ASN.1, and were fairly clearly ISO inspired. The observations of another ISO implementor (and security analyst) appear applicable: The specification was so general, and left so many choices, that it was necessary to hold implementor workshops to agree on what subsets to build and what choices to make. The specification wasn't a specification of a protocol. Instead, it was a framework in which a protocol could be designed and implemented. [Folklore-00] [Folklore-00] Perlman, R., Folklore of Protocol Design, draft-iab-perlman-folklore-00.txt, Work In Progress, January 1998. Quoting Photuris: Design Criteria, LNCS, Springer-Verlag, 1999: The hallmark of successful Internet protocols is that they are relatively simple. This aids in analysis of the protocol design, improves implementation interoperability, and reduces operational considerations. Compare with Photuris [RFC-2522], where undergraduate (Keromytis) and graduate (Spatscheck, Provos) students independently were able to complete interoperable implementations (in their spare time) in a month or so So, no, some security folks didn't ignore this ;-) -- 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 [EMAIL PROTECTED]
ISAKMP flaws?
Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Perry E. Metzger writes: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.ht ml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? Broadly speaking, they're implementation bugs. The folks at University of Oulu are doing what developers around the world and across the industry should have been doing: they're writing test case generators that stress parsers. So far, they've been extremely successful against IKEv1, ASN.1, SNMP, and more. This should surprise no one and depress everyone. http://www.ee.oulu.fi/research/ouspg/protos/index.html is the home page for this project. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. Note that the abstract is Multiple Vulnerability Issues in Implementation of ISAKMP Protocol, with emphasis on Implementation of. It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things. Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Paul Hoffman writes: At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.h tml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. Note that the abstract is Multiple Vulnerability Issues in Implementation of ISAKMP Protocol, with emphasis on Implementation of. It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things. Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Sure, even relatively simple protocols can be implemented poorly, but complex ones have more places to go wrong. (It's instructive, I might add, to read RFC 1025, especially the part about dirty blows.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 2:29 PM -0500 11/15/05, Steven M. Bellovin wrote: I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Well, then we fully agree with each other. Look at the message formats used in the protocols they have attacked successfully so far. Humorously, security folks seem to have ignored this when designing our protocols. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
