[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft 03 of SKIP
General Comments
================
This draft is a great improvement over previous drafts, both in content
and in clarity.
1. The SKIP header does not have a checksum. What assures the
integrity of the SKIP header ?
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 ?
3. Why is sequencing dropped in draft 3 ? The n counter provides
a very coarse-grain playback protection. For interoperability,
section 6.3 specifies the n counter to be incremented once every
hour. Since nodes are only required to be synchronized within an
hour of each other, and packets are processed if the counter value
differs by 1, this opens a window of an hour or more. Use of
sequencing can provide better protection, if the implementation
takes care of sequence number prediction.
4. The draft requires use of several numbers which must be
assigned by IANA,
Certificate Discovery Protocol - Ports 6455, 6456.
SKIP Multicast GIK request port - to be assigned
Algorithm Discovery - SKIP_ICMP type 39
How about introducing message types and use only one port ? With
message format dependent on message type. For example,
Message Type
1 - Certificate request
2 - Certificate response
3 - Algorithm request
4 - Algorithm response
5 - Multicast group interchange key request
6 - Multicast group interchange key response
Specific Comments
=================
Page 6, paragraph 2
> 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.
Page 6, paragraph 3
> 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 ?
Page 8, paragraph 3
> Once the counter has moved forward, packets encrypted with the help of
> counter values that differ by more than 1 from the local n MUST be
> ejected.
As mentioned in general comments, if packets with counter value
differing by 1 are accepted, the window can be an hour or more.
This is very coarse playback protection.
Page 9, paragraph 1
> This counter value is passed in the field labeled "n" following the
> version and processing mode bits of the SKIP header described in Section
> 1.9.
There is no longer processing mode bits in the SKIP header.
The counter value n follows the next header field of the SKIP header.
Page 12, Section 1.7.2
> 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.
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 )
Page 17, diagram of SKIP header
Kp encrypted in Kijn, Sender/Receiver Master Key-ID, do not have
right borders of their boxes. Since these are variable length,
I suggest using a box that looks like
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
~ ~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Page 22, diagram of SKIP with AH
Missing sender/receiver Master Key-ID in the SKIP header.
Page 24, diagram of SKIP with ESP
Missing sender/receiver Master Key-ID in the SKIP header.
Page 24, paragraph 3
> The Opaque transform data is defined by the particular transform (such
> as DES-CBC in RFC 1827).
RFC 1827 is ESP. Should this be RFC 1829 ESP DES-CDC ?
Page 26, Section 1.13.3
> 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 ?
Page 27, paragraph 5
> 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 ?
Page 31, Section 2.2.1
> groups, we describe SKIP for RIPv2 [RFC 1388]
RFC 1388 is obsoleted by RFC 1723.
Page 32, diagram of SKIP with RIP V2.
Missing sender/receiver Master Key-ID in the SKIP header.
Page 33, paragraph 2
> The ICMP message is authenticated using RFC
> 1825 as the default authentication algorithm
An RFC is not an algorithm. Suggestion : using Keyed MD5 [RFC1828]
as the default authentication algorithm.
Page 34.
> The Algorithm discovery ICMP message:
0 1 2 3
> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | TYPE=SKIP_ICMP| CODE | CHECKSUM |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ~
> CODE should be interpreted as a bit field in the following way:
7 6 5 4 3 2 1 0
> +-+-+-+-+-+-+-+-+
> |I|P|M|C|N| res |
> +-+-+-+-+-+-+-+-+
The top diagram shows CODE occupies bits 0-7 of octet 1.
The lower diagram reverses the bits 0-7.
So is the I bit in bit 0 of octet 1 ? or Bit 7 of octet 1 ?
How about showing the diagram in the same orientation ? eg,
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|P|M|C|N| res |
+-+-+-+-+-+-+-+-+
or
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| res |N|C|M|P|I|
+-+-+-+-+-+-+-+-+
> The time field, Current Time, is set to the system's concept of current
> time in seconds since 0h Jan 1, 1900. This is identical to the Integer
> portion of the NTP timestamp.
If the time field is 32-bits, in seconds, it can accommodate a little
over 136 years beyond 1900, ~2036. How about increasing this to
64 bits ?
Section 6.3, n counter start time is 0h Jan 1, 1995. How about
having both use year 1995 ?
There is no description for the field Expected n. Is this always
present or present only when N bit is set (invalid n counter sent
in the packet) ?
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 ?
On Page 14, description of Master Key-ID, it states :
"More importantly, it allows non-IP entities, such as individual users,
to be identified using whatever name space is being used for them."
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 ?
> A host may force an ICMP message by sending a SKIP packet to the remote
> host with Kij set to zero.
force ? What if the remote host does not support Algorithm Discovery,
which is optional ? Suggest rewording "force", maybe induce or elicit.
Page 39, paragraph 2
Suggestion : Spell out CRL on first use of acronym.
Page 40, last paragraph
> "by-pass" channel for encryption.
Please explain that this means traffic between the two ports
are not encrypted.
There are numerous places in the document referrring to things described
later. These can be made to explicit references. Here is a list :
Page 5, Section 1.1
> Another mechanism, described later, relies on naming principals
> using the message digest of their DH public value.
described in section 1.4,...
Page 8, paragraph 2 and 3
> Recommended time units/counter update frequency and the agreed upon
> start time is specified later in the document.
specified in section 6.3.
Page 9, Section 1.3.2
> As before, n can be computed as the difference between an agreed upon
> start time (specified later in this document) and the current time.
specified in section 6.3
Page 17, paragraph 3
> Examples of protocols other than AH/ESP that may use SKIP are given later.
There is only one example described (RIPv2). Suggestion :
"An example ....... is described in section 2.2.1"
Page 18, paragraph 3
> For instance, it is possible to have a Crypt Alg which provides
> both encryption and MAC computation. This is further described in
> a later section.
described in section 1.13.3.
Page 24, paragraph 2 and 3
> The SKIP_SPI value is specified later in this document.
specified in section 5.2
Page 34
> The ICMP type field SKIP_ICMP is specified later in this document.
specified in section 5.5
Page 35, last paragraph
> Although, strictly speaking, an unsigned DH public value is not a
> certificate, this value is distributed using the optional certificate
> discovery protocol specified later.
specified in section 4.3
Section 4.3, paragraph 2
> An algorithm for choosing a particular certificate
> (essentially a Diffie-Hellman public value) when more than one exist is
> described later.
in section 4.4
Follow-Ups: