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

Extended comments on draft skip-03

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

Hi Ashar, everybody

I did reread the skip draft 03, and I still like it very much ;-)

Sorry to give this set of comments without exact quotes of the original,
they were written on the way...

I will give as few editorial comments as I can myself force to, as you 
requested, just let me say that section 1.1 and on still have some of the 
deficiences I mentioned in my comments to 02.

I would add the Non-Goal of authentication with nonrepudiation characteristics
as 1.7.5. You mention the problem with asymmetric signatures somewhere, 
perhaps this could be moved to here?

page 14, 'identify a particulay Kij'
                              ^typo

page 14, between 3th and 4th paragraph
Do we provide for the fact, that at any given time a machine may use
multiple Kij's over the same link? We could tell them that this really would
work -- you are not bound to one shared secret per link. Example: Use a
machine-specific DH value for NFS etc. AND use the smartcard-supplied shared 
secret for a telnet / X connection whatever. This could be an example for 
user-level keying in section 1.8. (I know this demands user-level stuff like
sockopt(), but that is not a problem here, I believe)

page 14, last paragraph
You introduce the notion of a 'principal'. Is this a user, a service, a
machine? (probably all of them, depending on the application of this key
distribution scheme)

I am now for some while thinking about the possibility to take an RSA
public value and somehow use it as an DH public value. (after conversion)
Is this feasible, secure & interesting? One wonders... ;-)

page 15, paragraph 1
(about hash of public value for naming purposes - which I like very much. 
This will be a good step for us testing certificate discovery interoperabi-
lity in december)
... a name and a public value. + However the binding between name and identity 
has to be provided in a secure manner, see also note in 4.1.

page 15, last paragraph
here the notion of the receiver master-key ID introduces itself. Some pages
earlier it was the 'Destination NSID'. I suggest to stick to either source
NSID & source Master-Key ID or sender NSID sender Master-Key ID. Same for
destination & receiver. And yes, this _is_ yet another editorial comment;-)

page 18, last paragraph
...All RESERVED fields will be set...
                       ^MUST

1.10, page 19, first paragraph
Authentication must follow encryption and/or compression, because...
							  ^drop the rest
I know I already mangled this paragraph once. If you do authentication
before encryption you could still check it after decryption. (Unneeded work
in the case of a modified packet). The becasue... part seems not relevant
to me anymore. (Probably I am overseeing something?)

1.12 page 21, 3th paragraph 
Note:...
Hmm. The cryptographic distinction in this case is the fact that anybody can
check (and generate) the integrity of the packet, but only those in
possesion of the shared secret may check (and generate) the authenticity of 
the packet. (never mind...)

In 1.12.2 you removed the fields to cover for the MAC computation - especially
the IPSO label field. Sigh. It was wise to do so. Still I enjoyed the
explicit and coarse listing from 02 of what implementors _have_ to do ;-)

Quote from 1826
   [Atk95a].  In some situations, users MAY choose to carry explicit
   labels (for example, IPSO labels as defined by RFC-1108 might be used
   with IPv4) in addition to using the implicit labels provided by the
   Authentication Header.  Explicit label options could be defined for
   use with IPv6 (e.g., using the IPv6 end-to-end options header or the
   IPv6 hop-by-hop options header).  Implementations MAY support
   explicit labels in addition to implicit labels, but implementations
   are not required to support explicit labels.  If explicit labels are
   in use, then the explicit label MUST be included in the
   authentication calculation.
Does this solve the IPSO problem I mentioned in the comments to draft 02?

What do you do in SKIP if e.g. only authentication is specified, and the
length field as described in RFC1826 is set to 0? This would mean no
authentication data.

AGAIN: (I mentioned this twice already, I fear) What to do if a SKIP header
with Kij alg/Crypt alg/MAC alg etc. == 0 comes in / is to be produced?
Do we declare this invalid? Do we just leave out 'Kp' in the appropriate
cases (dropping the field) so we can still have compression without the
rest? I would somewhere set up a table of possible zeros, and discuss (il-)
legaility of the different cases. We want to operate in the same way, don't
we? ;-)

Kij alg | Crypt alg | MAC alg | ESP header | AH header | (RFC 1826 length)
========+===========+=========+============+===========+==================
   0    |      0    |    0    |  not pres. | not pres. |       -----      1)
   0    |    non 0  |    x    |      x     |     x     |         x        2)
   0    |      x    |  non 0  |      x     |     x     |         x        2)
   0    |      x    |    x    |      x     |  present  |         x        2)
 non 0  |      0    |    0    |      x     |     x     |         x        3)
 non 0  |    non 0  |    x    |  not pres. |     x     |         x        2)
 non 0  |    non 0  |    x    |   present  |     x     |         x        4)
 non 0  |      x    |  non 0  |      x     | not pres. |       -----      2)
 non 0  |      x    |  non 0  |      x     |  present  |       non 0      4)
 non 0  |      x    |  non 0  |      x     |  present  |         0        5)

Instead of ESP and/or AH header, this could be a RIP header with(-out)
authentication etc.

1) legal. Kp field not present. Usefull e.g. for compression without rest.
2) Illegal. Discard packet.
3) Illegal. Discard packet. How would you try to determine length of Kp...
4) Perfectly decent.
5) You tell me. Sounds quite stupid...

If there is a SKIP header, and AH ESP attached, but the SPI is non-1 should
we just ignore the SKIP header, and do different AH/ESP processing, or drop
the packet? (drop it! ;-)

Force ICMP answer with setting all alg fields to 0, including compression,
as opposed to the method stated in the last paragraph of section 3.

Oh yes. If we have an SKIP IP packet without trailing data of any form,
but with a nice random Kp, how does Sunscreen do? Pass it on? Yet another 
sublime channel? ;-)

Let's go back to SKIP:

1.13.1 / 1.13.2 The small images of 'IPv4 with SKIP/(AH)/ESP Example'. After
ESP header I would write 'opaque transform data' instead of 'Upper Protocol'.
It is not clear if after the ESP header there is an UPPER protocol (might be 
IP again) -- and you really can't look into it.

The last line of the image on page 24 should be the same as the one in the
image of page 25. (Usage of E_kp) On both images, the 'opaque transform
data' is only partially ESP hdr. The rest is payload. (Delimiter at the
border of the image)

1.14, 2nd paragraph, 1st line
...payload of of a...
             (--)


ICMP vs. Multicast
What happens if somebody in a multicast tree receives an incomprehensible
SKIP packet? Does he send an ICMP? (No! Well, maybe...) To the sender, or 
to the group? (To the sender!) How does the sender find out the feedback
concernes the group, and not the bilateral connection they perhaps also
have? This might be an issue when we go on and _do_ SKIP on multicasts.

Times
Sometimes you use time since 1.1.1995, sometimes since 1.1.1970 (if I 
remember right), sometimes seconds since 1.1.1900 (64 bits) and sometimes 
since 1.1.1900 in NTP format (integer part, 32bits). Many different 
representations. Now it is clear we use 'n' on an hourly base, and
it is okay to subtract about 788'400'000 (how much, exactly -- what about 
the infamous leap seconds ;-) )  from system time before using it.
But why using NTP format, when the internal timing represenation most
naturally available on the system is 'seconds since 1970'? I wonder...

Page 28, Multicast Request. I gather 'reply attacks' do not work because a
minimum of SKIP/AH is required. Do we want to note this? Or do we want to
add a time field like in the authenticated ICMP message? (Either one time
field is superflous, or there is one missing). Same for the Multicast reply
providing the GIK?

You define key change police for the multicast case. The same policy is very
reasonable in the unicast-case too. You could reference section 6.2 in the
first paragraph of page 29.

I enjoyed the introductor paragraph to section 3.0. How true !

page 33, paragraph 2, second line
...The ICPM message is authenticated...
                    ^MUST be

Hmmmm... Assume 2 hosts are out of sync concerning their 'n'. Perhaps due
to a different n scheduling, the posibility of this being suggested by the
draft somewhere. Now, when the authenticated ICMP message comes in, it will
be discarded because of the invalid n. But in the packet, the correct n
would have been given. Quite a dilemma, isn't it? Comments?

Page 35, first paragraph. I suggest to state that the minimal 'n' update
Frequencey (or rather, the grace period for accepting older n) shold be at
least as large as the time IP packets are expected to live in the network. I
seem not to remember the correct name at the moment. Something like maximum
packet latency or living time or whatever. Let's make it TTL ;-) Well,
perhaps this would fit better in 6.3.

[Comments about Certificate Discovery suppressed]

That's about it. The draft really is good work, and in my belief going into
the right direction. I look forward to the standard! ;-)

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

iQCVAwUBMI2ozLH8jId7euXhAQEjBwP/Sl5gy2DHYKgU3tVSevCMEupCls/LJyMX
XP5xUuCLJ1lRvweBZZNICBxLv29I1tc/BxqNK8IW0ucuuHuVJkqVCSEUdZA9qXuB
qnmUm8Em1DbsTwMRc1biBAt7MaLOrgYcYfAIfnpFMDCk+biQZM9BbkltvGNfTIh/
3ZBBt+/o7qI=
=dZOy
-----END PGP SIGNATURE-----