Subject: [secdir] Secdir review of draft-ietf-mip4-generic-notification-message-09

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Sep 2009 21:32:36 -0700

have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I have primarily focused on the security considerations section in this
document.  I also quickly reviewed the rest of the document.  Based on
my review I have the following comments:

1. In section 4.1, Identification

It states "nonces" are optional.  Nonces are not mentioned in the rest
of the document.  This option should be removed.  

2. Section 4.1, extensions

I found this section confusing as to when the AE is required.  It seems
the document states that the AE is always required, however it also uses
optional.   For example its not clear to me what is required in the case
given is section 3.2.

3. Section 4.2, extensions

Shouldn't the AE be required for GNAM?

4. Security considerations Section 8

It also wasn't quite clear to me when the AE is optional and mandatory.

5. Section 8.1

There are several places in the document where different replay
mechanisms are alluded to, included this section.  This section states
that nodes must agree on the mechanism used.  However there appears to
be no way to signal what mechanism is in use.  Is this assumed to be
pre-configured in each node, or is there another mechanism for this?  Is
this realistic for deployments? 

6. Section 8.1.1

NTP RFC 1305 needs to be included in the normative references.

Why is it important "those bits which are not available from a time
source SHOULD be generated from a good source of randomness" ? (it seems
that you don't really want bits to be random since you want to enforce
ordering)

This section also talks very briefly about clock synchronization.  It
seems there could be security implications here.  One node may be able
to poison a clock to an in appropriate value.  There probably should be
more discussion here.  

7. Section 8.2 

This section makes a statement but does not describe how impacts the
security of the system.  Since authentication is not performed can you
use the extension defined in the document in this case?  What is the
effect of the lack of authentication.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Sep 2009 09:11:42 +0300

Thanks for your review! Authors, do you have suggested text edits and/or 
a new draft version to address these?

Jari

---

From: Hui Deng <[email-masked]>
Date: Wed, 9 Sep 2009 00:31:58 +0800

Dear Joseph Salowey

Thanks for ur kind help, the draft has been updated to version 11
based on ur major comments
reply inline.

> of the document.  This option should be removed.
based on mip4's discussion, nonces section has been updated

> optional.   For example its not clear to me what is required in the case
clarify by indicate which AE is mandate and which AE will be optional

> Shouldn't the AE be required for GNAM?
updated

> It also wasn't quite clear to me when the AE is optional and mandatory.
Updated in Message sections.

> this realistic for deployments?
signal will be mobility security assocation as defined by the
mobility security association between them, and SPI value
in the authorization-enabling extension

> NTP RFC 1305 needs to be included in the normative references.
yes

> that you don't really want bits to be random since you want to enforce
remove this

> to poison a clock to an in appropriate value.  There probably should be
if poison, will discard it

> effect of the lack of authentication.
added.

thanks again.
Best regards,

-Hui