Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07

From: Sean Turner <[email-masked]>
Date: Mon, 14 Sep 2009 10:45:03 -0400

I 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.

This ID is intended for the Standards Track.  It defines an efficient 
way to resume an IKE/IPsec session using a previous established IKE SA 
without the need to re-run the key exchange protocol from the beginning. 
  The approach is similar to that used by TLS session resumption, but 
modified for IKEv2.

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

Technical comments:

4.3.1 does not require gateways to reject reused tickets (it's a 
SHOULD).  Shouldn't there be some text in the security considerations 
about gateways accepting reused tickets or text to say it's not a 
security consideration because of x, y, and z?  It's different than the 
considerations put forth in 9.8 because it addresses why the client must 
not present reused tickets.

4.3.2 states: "The client SHOULD NOT use this exchange type unless it 
knows that the gateway supports it."  What is the mechanism to determine 
whether the gateways support these new exchanges?  What happens when the 
client sends a request and the gateway doesn't support the response? 
What error message is returned from the gateway?  This might all be 
defined elsewhere in the IKE suite of specs, but this ID should probably 
point to that text wherever it is.

Editorial comments:

4.3.2: Should the may be MAY in the following: The first message may be 
rejected in?

4.3.2:  r/value ./value.

5: Note 6 is missing a ")"

6.1: r/MUST be protected so that only unauthorized access is not 
allowed/MUST be protected so that only authorized access is allowed

9.3: r/as possible. and/as possible, and

Cheers,

spt

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 14 Sep 2009 18:34:42 +0300

Hi Sean,

Thanks for your comments. We will address them in the next version of the draft.

Regarding your second technical comment: the draft specifically only allows resumption to the same gateway that issued the ticket. And this gateway supports the new exchange, by definition, which makes our text sort of redundant.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sean Turner
> Sent: Monday, September 14, 2009 17:45
> To: secdir; [email-masked]
> Cc: [email-masked]
> Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-resumption-07
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 16 Sep 2009 10:41:08 +0800

I 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.
In general, from the security point of view, this draft does not specify what 
the loghost should do in case of packet loss, DoS attack, etc. Should the 
device try to retrieve the sys log information again? 
 
Section 1, third paragraph (talking about Certificate Block): not to 
over-complicate matters, but this is really talking about the content of a 
Payload Block. Rather than introduce that term, perhaps rephrase the paragraph 
slightly to make clear that multiple Certificate Blocks may be used. What's the key management information here? Is it Certificate information or public key information?

    Additionally, a signer sends Certificate Blocks to provide key
    management information between the signer and the collector.  A
    Certificate Block has a field to denote the type of key material
    which may be such things as a PKIX certificate, an OpenPGP
    certificate, or even an indication that a key had been pre-
    distributed.  In the cases of certificates being sent, the
    certificates may have to be split across multiple Certificate
    Blocks carried in separate messages.

Section 1, fifth paragraph, first sentence: not clear what "previous" refers to. 
The phrase "of the previous messages" doesn't seem to add anything and can be 
dropped. Suggest adding "syslog" after "received" and "corresponding" before 
"Signature Block", so the sentence reads:

    The collector may verify that the hash of
    each received syslog message matches the signed hash contained in the
    corresponding Signature Block.

Section 4.2.3: It is strongly suggested that the field currently identified as 
Signature Group (SG) be renamed to Signature Group Interpretation (SGI) to avoid 
confusion. The statement that SPRI identifies the actual signature group also 
comes a bit late (beginning of the fourth paragraph). It should be moved up to 
the first paragraph.

Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 and IANA considerations. Note also that the field is called SIG instead of SG in section 5.3.2.3.
In section 5.3.2, P23, what's the main difference between using Signature block and using Certificate block? It seems Certificate Block overlaps with Signature Block, e.g., Both block are digitally signed, why is only certificate block termed "certificate block", why not term certificate block as "signature block"?

In section 5.3.2.9, the point is made that the timestamp of the Certificate 
Block message is the same as that of the Payload Block. In fact, they differ 
very slightly in the example. Is that intended?

In section 6, near the bottom of the first paragraph, a couple of words are 
missing. It is suggested that the sentence be changed to read:

                                                                     The
    collector MUST ignore duplicates of Signature Blocks and Certificate
                          ^^^^^^^^^^^^^^
    Blocks it has already received and authenticated.

Section 7 is informative. Perhaps it belongs in an appendix.
 
In section 7.1, 
 4.  Set the last message number processed to the value of the
           First Message Number plus the Count of the Signature Block
           minus 1.
Why is the Last message number not defined in this document?
 
In section 8.1,
 This specification uses Public Key Cryptography technologies.  The
   proper party or parties have to control the private key portion of a
   public-private key pair.  Any party that controls a private key can
   sign anything it pleases.
 
As regarding the last sentence, Is it appropriate to use "pleases" here? How about using *favors* or *prefers* instead of *pleases*?
 
In section 8.2,
As a signer, it is advisable to avoid message lengths exceeding 2048
   octets.  Various problems might result if a signer were to send
   messages with a length greater than 2048 octets, because relays MAY
   truncate messages with lengths greater than 2048 octets which would
   make it impossible for collectors to validate a hash of the packet.
   To increase the chance of interoperability, it tends to be best to be
   conservative with what you send but liberal in what you are able to
   receive.
 
   From the above paragraph, we can see it is necessary to restrict
   the length of message, So I would like to suggest changing the last
   sentence as:
   "
   To increase the chance of interoperability, it tends to be best to 
   limit the length of what you send but loose what you are able to
   receive.
   "
   to make it more precise. Is it reasonable to do this?

In section 8.3,
Syslog does not strongly associate the message with the message
   originator.  That association is established by the collector upon
   verification of the Signature Block. 
   
What's the difference between associating the message with the message originator
and signature? If they are the same thing, I think the association should be pre-established
in collector? Is it a correct understanding?

In section 8.4,
Event messages might be recorded and replayed by an attacker.  Using
   the information contained in the Signature Blocks, a reviewer can
   determine whether the received messages are the ones originally sent
   by an originator.  The reviewer can also identify messages that have
   been replayed.

I am wondering what the information is in the signature block can be used to
prevent replaying? Count or sequence number, time stamp, if there is such thing, it is better to
point it out which field of signature block is used for anti-replaying.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

---

From: Tina TSOU <[email-masked]>
Date: Wed, 16 Sep 2009 11:03:25 +0800

Sending to [email-masked]

B. R.
Tina

  ----- Original Message ----- 
  From: Tina TSOU 
  To: [email-masked] ; secdir 
  Cc: [email-masked] ; [email-masked] 
  Sent: Wednesday, September 16, 2009 10:41 AM
  Subject: [secdir] secdir review of draft-ietf-syslog-sign-27

                                                                       The

  In section 7.1, 
   
  In section 8.1,

  In section 8.2,

  In section 8.3,

  In section 8.4,

   

  B. R.
  Tina

------------------------------------------------------------------------------