[sipcore] FW: OPS-DIR review of draft-ietf-sipcore-sec-flows-06

[<[e-mail]>]

From: Black, David 
Sent: Friday, December 03, 2010 3:25 PM
To: Cullen Jennings; [e-mail]; [e-mail]; [e-mail]; '[e-mail]'
Cc: Black, David; Adam Roach; Paul Kyzivat
Subject: OPS-DIR review of draft-ietf-sipcore-sec-flows-06

I have performed an Operations Directorate review of draft-ietf-sipcore-sec-flows-06

Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones.  Improving the documents is important, but clearly a secondary purpose.  A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents.

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

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

This draft is aimed at improving the productivity of SIP over TLS interoperability events and the interoperability of SIP over TLS implementations.  As such, it's a positive contribution to network operations and management, as improved interoperability reduces operational issues that would otherwise arise.

I found a few nits and have a few suggestions:

The CA certificate uses a 1024-bit RSA key, whereas the host and user certificates use 2048-bit RSA keys.  This results in using a 1024-bit RSA key to vouch for the validity of 2048-bit RSA keys.  While acceptable for interoperability testing, this is not good operational security practice - I would suggest asking a PKIX expert (e.g., Steve Kent) for appropriate language to warn about this.

At the end of Section 2.2, the Section citation from RFC 5280 is wrong.  Sections 6.1 and 6.2 should be cited, instead of just Section 6.1.4.  Also, the CRL checking in Section 6.3 of RFC 5280 should be added as a reference cited in the last paragraph of the security considerations section.

Somewhere, probably in Section 5, a warning should be added that the certificate path validation algorithm is a complex algorithm for which *all* the details matter - there are numerous ways in which failing to precisely implement the algorithm as specified in Section 6 of RFC 5280 can create a security flaw, a simple example of which is the failure to check the expiration date that is already mentioned in Section 5.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------