[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft 03 of SKIP



-----BEGIN PGP SIGNED MESSAGE-----

Teodora Ngo wrote:
> Subject: comments on draft 03 of SKIP

I allow myself to comment your comments, as I have a strong opinion on some
of them. I enjoyed reading them, even when I disagreed. There is no advance
without contrasting opinions! ;-)

> 1. The SKIP header does not have a checksum.  What assures the
>    integrity of the SKIP header ?

If the packet is authenticated, then this provides the integrity check.
If not then the encapsulated packet will be decrypted wrongly, and the 
next protocol field, the upper protocol checksum, or the data will be 
junk. This will be discovered at the appropriate level. SKIP implemen-
tations may check some of these conditions after decrypting.

> 2. There are two modes in ESP, tunnel mode and transport mode.
>    This information is not on the SKIP header.  How does an
>    intermediate node which is encrypting/decrypting SKIP packets 
>    for multiple machines know whether the entire IP datagram is
>    encrypted or only the upper-layer protocol ?

a) does it matter?
b) by looking at the next protocol field.

> 3. Why is sequencing dropped in draft 3 ?  The n counter provides

That is a *very* good question. I would like to see this feature back,
either in the ESP transform, the AH transform, or somewhere else. I believe
you, Ashar, have a solution to this up your sleeve?!

>    How about introducing message types and use only one port ?  With
>    message format dependent on message type.  For example,

Only one port would *FORCE* the one binding to the port to understand all 
of these. But my certificate broker will never want to bother with multicast
access control at all... A different question is, why do you have different 
ports for sender and receiver? Frankly, I do not know. No need for this?

>   > Once n certificates are assigned to n IP nodes, O(n^2) mutually
>   > authenticated pairwise keys arise, simply as a result of the
>   > authenticated public value distribution process.
> What is the notation O(n^2) ?  In Math Probability, there is a combination
> function, nCj = n! /[(n-j)! j!], which is the number of ways of selecting
> j objects out of n objects.  nC2 maps nicely into the number of pairwise
> keys from n certificates.  Perhaps one can change the notation to use
> C(n,2) instead of nC2.

Given the above example, we could also just write n(n-1) instead of O(n^2)
which would be the exact answer in the given scenario.
The 'O' notation IMHO expresses 'on_the_order_of' computational behaviour.

>   > Since there is nothing secret about DH public values, one natural way 
>   > to discover the relevant authenticated _public value_ is to distribute 
>   > these using a directory service.
> authenticated directory service ?
> Does this require a secure directory or naming service ? 

no authenticated _directory service_ is needed here.

>    > and that should be infeasible even given a very large number of
>    > known/chosen Kp keys as long as the key-encryption algorithm is immune
>    > to a chosen text attack, which will always be the case.
> always be the case ?  depends on key-encryption algorithm chosen.

I strongly agree.

> Page 14, paragraph 6
> > The usage of NSIDs also allows many different name spaces (up to 256) to
> > be used with SKIP, by letting the Master Key-ID be the message digest of
> > the name in its native name space. 
> If the Master Key-ID is the message digest of the name in its name space,
> it will be unique only if the message digest is collision resistant.
> It is possible to produce collitions in the compression function of MD5.
> ( B. den Boer and A. Bosselaers )

########################################################################
Let me quote parts of a mail from
Sender: "paul (p.c.) van oorschot" <paulv@bnr.ca>
Date:  Mon, 26 Jun 1995 18:26:00 -0400
Subject:  response to Last Call on: IP Authentication using Keyed MD5
which can be found in the ipsec mailing list archive.

...                                           Regarding attacks on
   specific hash functions, the I-D notes an attack on the compression
   function of MD5 by den Boer and Bosselaers, and states:

    ``There is not yet a known method to exploit these collisions
      to attack MD5 in practice, but this fact is disturbing to some
      authors [Schneier94].''

   Indeed, considerable additional research has been recently carried out.
   Bert den Boer himself proposed a new hash function, namely RIPEMD,
   which was analyzed under the European RACE/RIPE consortium in 1992.
   RIPEMD is a ``very strong'' version of MD4 involving essentially two
   strengthened versions of MD4 running in parallel.  It was designed
   to counter known two-round attacks on MD4 and MD5.  However, more
   recent cryptanalytic work on MD4 by Vaudenay [md4-attack] and on
   RIPEMD by Dobbertin [ripemd-attack] suggests that both MD4 and
   (very likely) MD5 fail to be as resistent as previously believed
   to manipulations of their internal structures.

   As a result of this work, some European researchers now believe that
   collisions for MD4 and MD5 themselves (rather than just for their
   compression functions) may soon be found by similar techniques.
...
#########################################################################

and from a private communication with Shahram Bakhtiari H. L. (3.2.95)
...
Note: Psudocollision for MD5 that is proposed by two fellows, cannot
find Psudocollision when one of the initial vectors is fixed (secret).
They start from the middle point and sometimes can find two initial
vectors (which only differ in 4 bits) for MD5. Therefore, if you fix
the initial vector, they cannot find the other that collide with it.
...
#########################################################################

just to remind myself and you, patient readers, why keyed-MD5 is being used 
in AH, and that it *might* be broken any day now. There are alternatives,
and they were proposed. Oh well.

Now, back to the issue of a single hash for two different (legal) names, and
two different keys that are bound to it by cryptographic means. If the
collision happens by accident, a user will experience denial of service,
because the side in error will use the wrong DH public value. No way to fix
that, collisions *may* always happen where a compression is involved.

But if the collision can be willfully achieved for a man-in-the-middle 
attack (I remember somebody announcing that ONE collision has been achieved,
I am sorry but I do not remember the details), SKIP is doomed. We can use 
another hashing algorithm, which is supposedly more secure. (e.g. SHA, 
Tandem Davis-Meyer, or MDx-MAC [crypto95]) What else could we do? Until we
have no vastly better solution than MD5, I suggest staying with MD5!

Comments anyone?

>    > For ESP transforms which combine encryption and authentication (for
>    > instance: Keyed MD5 with DES-CBC), only an ESP header is needed.
> What is being specified ?  Is it allowed to have both AH and ESP headers ?
> Or It MUST only contain the ESP header, without AH header ?  
> What is the assigned algorithm number for this combined transform example,
> Keyed MD5 with DES-CBC ?

I suggest to forbid the existence of a separate Ah header, as the
corresponding MAC Alg has been allocated for the combined transform.

>    > Nodes wishing to transmit/receive encrypted datagrams to multicast
>    > address M need to acquire the GIK Kg. This is done by sending an
>    > encrypted/authenticated request-to-join primitive to the group owner.
> How will this be encrypted/authenticated ?  Using unicast SKIP ?

Yes. This is stated in the paragraph you quoted, just 3 lines below.

[about missing sender/receiver ID fields]
they are optional, and thus need not be present in all pictures.

>    In RFC1825 (Security Architecture), it states :
>    "Given two endpoints, it MUST be possible to have more than one
>    concurrent Security Association for communications between them."
>    Does this draft address this requirement ?

It does not forbid this. And it allows user-dependant keying information.
Additionally, 1825 is stated as a base for SKIP. I belive it is job of the
implementor to be conformant to 1825. The draft suerely is, by not
forbidding this. Additionally, implementations should produce a lot of
syslog output in the case of conformance with 1825. Which will cause each
garbled packet to be logged. sigh.


>    The Algorithm discovery message does not contain NSID nor Master Key-ID.
>    Will this allow different encryption algorithms to be used for
>    different Master Key-IDs ?  or between two systems ?

I see no need for multiple encryption algorithms between two machines at one
point in time.

Comments anybody?

> Page 39, paragraph 2
>    Suggestion : Spell out CRL on first use of acronym.

YES!

> Page 40, last paragraph
>    > "by-pass" channel for encryption.
>      Please explain that this means traffic between the two ports
>      are not encrypted.

And not authenticated!

> There are numerous places in the document referrring to things described
> later.  These can be made to explicit references.  Here is a list :

See my comments to (02). Thank you for backing my claim! I am sure this can
be done when editorial changes are ellicited.

Friendly greetings,

	Germano

- -- 
<...cookie space for rent...>

Germano Caronni    caronni@tik.ee.ethz.ch    http://www.tik.ee.ethz.ch/~caronni
PGP-Key-ID:7B7AE5E1    gec@acm.org             997C6DC4AF930A5D2D5D6AEAA196C33B

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMJAqXrH8jId7euXhAQE/4wQAqgyYdQYhFq5LjhGpw7NLHBm76LXDh9xM
ZML4X25yLqUml73+EBWCKuKLRX6yayz6ygEFYCZUOWjXdxpB6XqzpjOIfnigXEvc
3Roc5kC1PVkRhldFYrVbnZbRPmD4yQ6gL4aV5RTjRadG5WAZCxzHyOYOSWmfvCqi
4yKpc9kJrc4=
=ySjx
-----END PGP SIGNATURE-----


References: