Ralph Holz <[email protected]> writes:
>BTW, almost all protocols lack a definition of what they mean by
>"authentication", too. Cas Cremers showed that IPSec authentication is broken
>for a number of definitions, although fortunately not for "the intuitive one"
>and the one it was probably designed for. I suspect the same holds for SSL.
Protocols don't just not define "authentication", they don't even bother
specifying that you should apply it. For an upcoming article on fault-
injection testing in ;login I looked through the specs for a pile of Internet
security protocols and found that you can create a fully standards-compliant
implementation that looks at a signature or MAC tag, throws it away, and
continues. An excerpt:
This problem is widespread among security standards. The OpenPGP
specification, which devotes a full fifteen pages to the minutiae of the
formatting of signatures and signature data, completely omits to tell you
what exception conditions need to be checked for when processing signatures
or how to respond to them (the only comment in the standard that I could
find was a statement that “If a subpacket is encountered that is marked
critical but is unknown to the evaluating software, the evaluator SHOULD
consider the signature to be in error” [REF]). The standards that cover SSH
are no better, with the sole check that’s required being that “values of
[Diffie-Hellman parameters] that are not in the range [Diffie-Hellman prime
size] MUST NOT be sent or accepted by either side” [REF]. As long as an
implementation checks those parameters, it can ignore the signature validity
check and be completely standards-compliant.
I was... somewhat surprised at this.
Peter (whose nonstandard implementation checks signatures and MACs and rejects
the message if the check fails).
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
