Last Call Review of draft-ietf-martini-reqs-
review-ietf-martini-reqs-secdir-lc-orman-2010-06-24-00

Request Review of draft-ietf-martini-reqs
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-22
Requested 2010-06-09
Authors John Elwell, Hadriel Kaplan
Draft last updated 2010-06-24
Completed reviews Secdir Last Call review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-martini-reqs-secdir-lc-orman-2010-06-24
Review completed: 2010-06-24

Review
review-ietf-martini-reqs-secdir-lc-orman-2010-06-24

Security review of draft-ietf-martini-reqs-07.txt,
Multiple AOR reachability in SIP 

Do not be alarmed.  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.

The abstract:
 This document states requirements for a standardized SIP registration
 mechanism for multiple addresses of record, the mechanism being
 suitable for deployment by SIP service providers on a large scale in
 support of small to medium sized Private Branch Exchanges (PBXs).
 The requirements are for a solution that can, as a minimum, support
 AORs based on E.164 numbers.

There are 21 requirements, and two of them address security.

I think requirement 14 leaves out a couple of things:
  REQ14 - The mechanism MUST be able to operate over a transport that
  provides integrity protection and confidentiality.
It should probably require "end-to-end" integrity protection and
confidentiality between the two entities (SIP-PBX and the SSP).

And I think requirement 15 should say something about how the two
entites are expected to agree on an authentication method, and that
the authentication should apply to every registration message
exchanged by the entities.  That is, once they have authenticated,
then that information should be tied to requirement 14 and ensure that
the integrity and/or confidentiality is defined between the two
entities (by use of, for example, an authenticated key exchange
protocol) on all subsequent messages between the two.  
   REQ15 - The mechanism MUST support authentication of the SIP-PBX by
   the SSP and vice versa.
I'd also add that it MUST support termination of authenticaton and
re-authentication.

Minor non-security things:

Requirement 4 has a triple negative ("not" "prevent" "without"), and
I'm not sure what the heck it means.

Requirement 5 has a typo, probably "internally" for "internal".

Hilarie