Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
draft-ietf-sipping-e2m-sec-reqs-06

State Change Notice email list have been change to gonzalo.camarillo@ericsson.com, dean.willis@softarmor.com,  rohan@ekabal.com, ono.kumiko@lab.ntt.co.jp, kumiko@cs.columbia.edu from gonzalo.camarillo@ericsson.com, dean.willis@softarmor.com,  rohan@ekabal.com, ono.kumiko@lab.ntt.co.jp

[Ballot discuss]
This document discusses digest authentication as if it is an
end-to-middle service.  Digest authentication is a hop-by-hop service
last time I checked.  I'm confused; what is really meant here?

[Ballot comment]
Reviewed by Suzanne Woolf, Gen-ART

Her review:

This document seems to be in pretty good shape to be published as
Informational; it motivates the need for e2m and describes the
characteristics of successful e2m security for SIP.

However, I have some reservations. I may have found it hard to follow
simply because I know little about the underlying protocol. But it may
need to be clarified in several places, e.g. "This requirement is not
necessary when a provider that operates the proxy server does not
permit to reveal the security policies to a different provider that
the recipient UA belongs to." I *think* I know what it means but it
might be clearer to say "This requirement is not necessary when the
provider operating the proxy service does not allow its security
policies to be revealed to the provider serving the recipient UA."

[Ballot discuss]
Section 4 includes the following requirements:
  >
  > REQ-CONF-1: The solution MUST allow encrypted data to be shared with
  >            the recipient UA and selected proxy servers, when a UA
  >            wants.
  >
  > REQ-CONF-3: It SHOULD allow a UA to request selected proxy servers to
  >            view specific message bodies.  The request itself SHOULD
  >            be secure.
  >
  > REQ-INT-2: It SHOULD allow a UA to request selected proxy servers to
  >            verify specific message bodies.  The request itself SHOULD
  >            be secure.
  >
  I fear that "selected proxy servers" is not clear.  I think that the
  intent is to allow encrypted data to be decrypted by proxy servers
  chosen by the UA and to specifically request that these proxy servers
  perform decryption and/or integrity checking.  This implies that the UA
  can unambiguously identify proxy servers.  In the are of confidentiality,
  the UA also needs to obtain credentials (such as a certificate) for the
  proxy server.  In the case of integrity, similar credentials will be
  needed to support a message authentication code (such as HMAC), but
  they are not needed is a digital signature is used.

  Section 4 includes the following requirements:
  >
  > REQ-CONF-3: It SHOULD allow a UA to request selected proxy servers to
  >            view specific message bodies.  The request itself SHOULD
  >            be secure.
  >
  > REQ-CONF-4: It MAY allow a UA to request that the recipient UA
  >            disclose information to the proxy server, to which the
  >            requesting UA is initially disclosing information.  The
  >            request itself SHOULD be secure.
  >
  > REQ-INT-2: It SHOULD allow a UA to request selected proxy servers to
  >            verify specific message bodies.  The request itself SHOULD
  >            be secure.
  >
  > REQ-INT-3: It SHOULD allow a UA to request the recipient UA to send
  >            the verification data of the same information that the
  >            requesting UA is providing to the proxy server.  The
  >            request itself SHOULD be secure.
  >
  The term "secure" is unclear.  I assume that authentication and data
  integrity are the needed security services.

  Section 4.2 leads the reader to believe that data integrity can be
  provided without also providing authentication.  I do not believe
  that it is possible to provide data integrity in this context without
  also providing authentication.  This section should be rewritten to
  provide both data integrity and authentication.

  Section 5 says:
  >
  > This document describes the requirements for confidentiality and
  > integrity between a UA and a proxy server.  Although this document
  > does not cover authentication, it is important in order to prevent
  > attacks from malicious users and servers.
  >
  I do not believe that it is possible to provide data integrity in
  this context without also providing authentication.  This comment
  goes hand-in-hand with my previous comment.

  Section 5 talks about denial of service attacks.  I believe that the
  protections requested here can be provided by the hop-by-hop use of
  TLS.  The solution implied by the text in section 5 is less robust;
  it does not seem to consider an attacker generating traffic to a
  proxy server that looks like it came from another proxy server.

[Ballot comment]
Section 2.1: s/request base on/request based on/

  Section 2.1: ASCII Art is difficult, and often subjective.  To me,
  the following is more self-consistent.  In the original, I was asking
  myself if the inconsistencies meant anything, and I convinced myself
  that they did not.  Second, I propose "[C]" to denote a content that
  is protected.  This allows multiple layers of encapsulation to be
  shown if needed.

                    Home Network
              /---------------------\
              | +-----+    +-----+ |  +-----+    +-----+
    User #1-----|  C  |-----| [C] |-----| [C] |-----|  C  |-----User #2
              | +-----+    +-----+ |  +-----+    +-----+
              | UA #1      Proxy #1 |  Proxy #2    UA #2
              \---------------------/
 
  If you accept any of these changes, please consistently use them in the
  rest of the figures too.

  Section 2.2.1: The 2nd paragraph of this section should read:
  >
  > This service might be deployed in financial networks, health care
  > service provider's networks, as well as other networks where
  > archiving communication is required by their security policies.

  Section 4.1: I think the following revised text has the same meaning,
  but I think it is more straightforward:
  >
  > REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do
  >            not provide services based on S/MIME-protected bodies
  >            in terms of handling the existing SIP headers.

  Reference [4] should point to RFC 3850.

  Reference [6] should point to a specification of the Location Object,
  not the requirements for the location object.

[Ballot discuss]
In 2.2.2, the document says 

  The Location Object [6] includes private information as well as
  routing information for appropriate proxy servers.  Some proxy
  servers have the capability to provide location-based routing.  When
  UAs want to employ location-based routing in non-emergency
  situations, the UAs need to connect to the proxy servers with such a
  capability and disclose the location object contained in the message
  body of the INVITE request, while protecting it from other proxy
  servers along the request path.


[6] points to the GEOPRIV requirements document, but I believe they
should point to draft-ietf-geopriv-pidf-lo-03.txt, currently in the RFC
Editor's queue.  I'm also concerned that this paragraph does not
capture well how the privacy aspects of a geopriv object work.  The
question of to whom a location object may be passed is extensively
considered in geopriv, and describing it in the same terms would
be very helpful in matching the requirements here to the capabilities
of pidf-lo.

The document goes on:

  The Location Object also needs to be verified for integrity before
  location-based routing is applied. 

What does verified for integrity mean here?

[Ballot discuss]
In 2.2.2, the document says 

  The Location Object [6] includes private information as well as
  routing information for appropriate proxy servers.  Some proxy
  servers have the capability to provide location-based routing.  When
  UAs want to employ location-based routing in non-emergency
  situations, the UAs need to connect to the proxy servers with such a
  capability and disclose the location object contained in the message
  body of the INVITE request, while protecting it from other proxy
  servers along the request path.


[6] points to the GEOPRIV requirements document, but I believe they
should point to draft-ietf-geopriv-pidf-lo-03.txt, currently in the RFC
Editor's queue.  I'm also not concerned that this paragraph does not
capture well how the privacy aspects of a geopriv object work.  The
question of to whom a location object may be passed is extensively
considered in geopriv, and describing it in the same terms would
be very helpful in matching the requirements here to the capabilities
of pidf-lo.

The document goes on:

  The Location Object also needs to be verified for integrity before
  location-based routing is applied. 

What does verified for integrity mean here?