Subject: [MSEC] RE: More IESG Comments on draft-ietf-msec-mikey-07

From: "Karl Norrman (KI/EAB)" <[email-masked]>
Date: Thu, 23 Oct 2003 15:14:42 +0200

Dear all,

Here is our reply to the comments on "MIKEY" received so far.
We appreciate the reviewers input, it will certainly improve the
spec.

= = = = = = =
Comments from Steve Bellovin. 
= = = = = = =

4.1.3 says "let n = inkey_len / 512, rounded up to the nearest integer".
Is it rounded up, or to the nearest integer?  If the division yields an
integral result, is it bumped by 1?  The same comment applies to m.

[Reply:] We will clarify (that rounding up is done only when the
quantities are not already integers).

Explain what relevance 512 has to SHA1, which externally takes messages
of any size.  Are you referring to SHA1 internals?  What should be used

[Reply:] Considering the change suggested below, it should no longer be an 
issue, but we will clarify anyhow (refering to the "block size" and 
"message digest size" as used in the FIPS). 

for hash functions that don't have SHA1's internal 512-bit structure?
I suggest that you require than any new PRF be defined by its own RFC,
rather than trying to give guidance here.

[Reply:] We agree. Not becuase there would be any problem in specifying
the parameters in a clear way, but rather becuase the PRF is based on a 
HMAC construction using said hash, not on the hash directly. Therefore, 
Although HMAC_SHAx (x = 256, 384, 512) could easily be specified refering
to RFC2104 and FIPS 180-2, it would probably be "safer" to refer to an 
equivavlent of RFC2404 (but for SHA2), so since no such RFC exists, we will 
remove the option, unless we hear strong objection from the IETF community.

4.2.2: what parameters corresponding to 512 and 160 should be used for
SHA-256, -384, or -512?

[Reply:] Again, this could be easily defined (refering to FIPS 180-2)
but we will do as you suggested above.

4.2.9: what process (per rfc 2434) is needed for new parameter
registration?  How does this relate to Section 10?

[Reply:] Per RFC 2434, the following registration process should be 
used (from Sect 10, paragraph 2): 

   "...values in the range 0-240 for each name space
   should be approved by the process of IETF consensus and 
   values in the range 241-255 are reserved for Private Use."

A reference to 2434 seem to be lacking (so this will of course be 
added).

5.4 suggests dropping messages from attacking peers.  Of course, until
the message is authenticated you don't know whom it's from, which still
leaves the door open to a CPU DoS attack.

[Reply:] "Dropping" is intended to be based on source address filtering,
in which case there is no point in trying to authenticate messages 
from "banned" peers. Of course, this might mean that an attacker who 
can spoof IP addresses could "block" a legitimate user, causing other DoS
effect. As you say, it would therefore be more robust to actually do
the authentication. In the symmetric key case, it might indeed be feasible 
to really authenticate the source cryptographically up to quite high traffic 
rates, but there is of course always a limit above which we would need
to resort to more opportunistic ways... We should probably expand the text 
and elaborate on pros and cons of these approaches. 

5.5: what is done to avoid congestion?

[Reply:] We agree this section is perhaps too simplistic, and we
would consider dropping the section if it had not been for the
fact that we have some indication people want to run MIKEY over
e.g. UDP. Rather than giving a wrong impression on what adequate
reliability means, we propose the whole section is replaced by:

"MIKEY assumes reliable transport. If an unreliable transport protocol, 
 e.g., UDP, is used, a reliability mechanism MUST be added (see for 
 instance [Stevens])

 Reference:

 [Stevens] R. Stevens: 
 UNIX network programming: Networking APIs: Sockets and XTI,
 Prentice Hall, 1998 (Section 20.5)"

6.11 Cite RFC 1750?  (Also cite it when discussing DH exponents.)

[Reply:] Thanks, will do so. (Perhaps also in the beginning of the doc
size random/pseudo random is used here and there.)

= = = = = = =
Comments from Ted Hardie. 
= = = = = = =

This is a weak DISCUSS, and I could be pretty easily persuaded to drop it.
Essentially, I'm concerned about section 5.4, which describes the replay
protection mechanisms.  The language in the draft is a bit hard to parse
in places, and there seem to be some assumptions
that we may not be able to meet.  In particular, it cites as an assumption:

"* If the clocks are to be synchronized over the network, a secure
   network clock synchronization protocol is used."

[Reply:] First, since MIKEY's intention is not to specify a security 
solution of any specific timestamping protocol, "...is used." should 
be replaced by "...SHOULD be used."

Is there a solution available for this?  NTP v3 is cited in the references 
(not in this paragraph),
but I don't think that quite fits this bill, and the STIME work doesn't 
seem to be done.

The Security Considerations Section (9.3) does discuss this briefly, but 
basically points back
to 5.4 and hints that practical experience with other protocols indicates 
that manual configuration
may be okay.

[Reply:] There are indeed standardized secure time stamping protocols, and 
we should probably expand the list of references. What comes into
mind directly are the protocols of the ISO/IEC 18014 series.

This language also seemed strange:

   In a client-server scenario, servers may be the entities that will
   have the highest workload. It is therefore RECOMMENDED that the
   servers are the Initiators of MIKEY. This will result in that the
   servers will not need to manage any significant replay cache as they
   will refuse all incoming messages that are not a response to an
   already (by the server) sent message.

as it seems to imply that the initiation should follow a particular pattern,
regardless of the pattern of the underlying protocol.  In other words,
it sounds like it is recommending that clients wishing to initiate should
instead tell the server to initiate, then respond, so that the server replay
cache would not have to be large.  This wasn't entirely clear, though,
and some tightened language might help.

[Reply:] We agree the formulation is unclear. It could indeed be impractical
in some cases to arrange so that the server initiates. We will imporve
the wording.

In general, an editing pass through this section by a native speaker might
be a good idea.

[Reply:] Agreed.

/Mikey authors

 >-----Original Message-----
 >From: Russ Housley [mailto:[email-masked]]
 >Sent: den 21 oktober 2003 00:01
 >To: [email-masked]; [email-masked]; Jari 
 >Arkko (JO/LMF);
 >Elisabetta Carrara (KI/EAB); Fredrik Lindholm (KI/EAB); Mats Näslund
 >(KI/EAB); Karl Norrman (KI/EAB)
 >Subject: More IESG Comments on draft-ietf-msec-mikey-07
 >
 >
 >Here are some comments from Ted Hardie.  Comments may be 
 >coming from other 
 >Area Directors, but I thought I would pass these along so you 
 >could get 
 >started.
 >
 >Also, there are non-ASCII characters in the document.
 >
 >The document is on the agenda for 30 October.  It would be 
 >nice if the 
 >comments that I sent last week and these comment can be 
 >reviewed before the 
 >meeting.  If there are straightforward responses, I need to know them.
 >
 >Russ
 >
 >= = = = = = =
 >
 >This is a weak DISCUSS, and I could be pretty easily 
 >persuaded to drop it.
 >Essentially, I'm concerned about section 5.4, which describes 
 >the replay
 >protection mechanisms.  The language in the draft is a bit 
 >hard to parse
 >in places, and there seem to be some assumptions
 >that we may not be able to meet.  In particular, it cites as 
 >an assumption:
 >
 >"* If the clocks are to be synchronized over the network, a secure
 >   network clock synchronization protocol is used."
 >
 >Is there a solution available for this?  NTP v3 is cited in 
 >the references 
 >(not in this paragraph),
 >but I don't think that quite fits this bill, and the STIME 
 >work doesn't 
 >seem to be done.
 >
 >The Security Considerations Section (9.3) does discuss this 
 >briefly, but 
 >basically points back
 >to 5.4 and hints that practical experience with other 
 >protocols indicates 
 >that manual configuration
 >may be okay.
 >
 >This language also seemed strange:
 >
 >   In a client-server scenario, servers may be the entities that will
 >   have the highest workload. It is therefore RECOMMENDED that the
 >   servers are the Initiators of MIKEY. This will result in that the
 >   servers will not need to manage any significant replay 
 >cache as they
 >   will refuse all incoming messages that are not a response to an
 >   already (by the server) sent message.
 >
 >as it seems to imply that the initiation should follow a 
 >particular pattern,
 >regardless of the pattern of the underlying protocol.  In other words,
 >it sounds like it is recommending that clients wishing to 
 >initiate should
 >instead tell the server to initiate, then respond, so that 
 >the server replay
 >cache would not have to be large.  This wasn't entirely clear, though,
 >and some tightened language might help.
 >
 >In general, an editing pass through this section by a native 
 >speaker might
 >be a good idea.
 >

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec