Comments on draft-ietf-sip-gruu-10

GENERAL COMMENTS
I found this document very hard to read. At root, the
concept
is extremely simple, but the document is 40 pages. IMO it 
could stand to be put on a pretty serious diet. I realize
that this is an editorial comment, and I suppose it's not
necessarily a showstopper, but I think it presents a pretty
substantial obstacle to implementor understanding--at 
least it would if I were doing the implementation.

In particular, pages 13-23 contain descriptions of the
behaviors
expected of various elements in the system. It's quite hard
to tell
from the text which behaviors are new to this specification
and which
are simply inherited from other specs and being described
here for
expository reasons. For instance, here's S 8.1.2:

   There is no new behavior associated with sending a
request to a GRUU.
   A GRUU is a URI like any other.  When a UA receives a
request or
   response, it knows that the remote target is a GRUU by
the presence
   of the "gruu" URI parameter.  The UA can take
the GRUU, send a
   request to it, and then be sure that the request is
delivered to the
   UA instance which sent the request or response.

   If the GRUU contains the "opaque" URI
parameter, a UA can obtain the
   AOR for the user by stripping the "opaque"
and "gruu" URI parameters.
   The resulting URI is the AOR.  If the GRUU does not have
the "opaque"
   URI parameter, there is no mechanism defined for
determining the AOR
   from the GRUU.  Extraction of the AOR from the GRUU is
useful for
   call logs and other accounting functions where it is
desirable to
   know the user to whom the request was directed.

   Because the instance ID is a callee capabilities
parameter, a UA
   might be tempted to send a request to the AOR of a user,
and include
   an Accept-Contact header field [19] that indicates a
preference for
   routing the request to a UA with a specific instance ID. 
Although
   this would appear to have the same effect as sending a
request to the
   GRUU, it does not.  The caller preferences expressed in
the Accept-
   Contact header field are just preferences.  Its efficacy
depends on a
   UA constructing an Accept-Contact header field that
interacts with
   domain-processing logic for an AOR, to cause a request to
route to a
   particular instance.  Given the variability in routing
logic in a
   domain (for example, time-based routing to only selected
contacts),
   this doesn't work for many domain-routing policies. 
However, this
   specification does not forbid a client from attempting
such a
   request, as there may be cases where the desired
operation truly is a
   preferential routing request.

The only normative text here is the first sentence, which
tells us that
there's no new behavior. The rest is purely expository.
After reading
it, I'm not sure that it's necessary at all, but if it is
it should
be clearly separated from the normative text. I would advise
trying 
to separate the new normative behavior into separate
sections. 

I would advise intermixing examples with the main text and
then
having an extended example at the end. Just having a single 
extended example that people have to refer back to makes it
very hard to get the idea of what's going on.

TECHNICAL COMMENTS
I'm a bit concerned about a lack of generality in this
design.
At some level, the idea here is that you have some URI X and
you'd like to be able to create subordinate URIs XY and XZ
such that they both correspond to X in (at least the
following
ways):

  0. Either XY or XZ can speak for X.
  1. A peer can address X and he will end up speaking to
     XY or XZ.
  2. A peer can directly address XY and XZ and will end up
     at the right place.

This specification provides two mechanisms for doing this:

  1. opaque=, which is switched at the proxy.
  2. grid=, which is switched at the end-instance.

This seems like a not very general design. In particular, it
would be able to use the same mechanism (e.g., name
extension).
Second, it seems like there's a real possibility we might
want
to be able to perform this same trick in some other context,
in which case won't we need to invent some new
demultiplexing
indicator? It may be too late to redesign things to this
extent, but that doesn't mean this isn't a real issue.

Why is it necessary to have GRUUs which are (1) identifiable
as GRUUs to peers but (2) can't be translated back to the
AOR
by the peer?

EDITORIAL COMMENTS
Abstract:

   Several applications of the Session Initiation Protocol
(SIP) require
   a user agent (UA) to construct and distribute a URI that
can be used
   by anyone on the Internet to route a call to that
specific UA
   instance. 

I would add after this "as opposed to the AOR, which
may map to
multiple UA instances"

S 1:
I don't find this section very clear at all. It manages to
hide
the key point about wanting to be able to address specific
UAs
rather than the AOR sort of implicitly in para 2.

I would take one such one of the examples in S 4 and glue
it in here to make clear what the issue is. I would remove
paras 3 and 4 entirely. I think they're not adding much
value.

S 2:
Isn't the key point for "contact" that it's
bound to a specific
UA?

S 3:
I'm not sure that this discussion of properties adds a lot
of 
value. It's not really referred to much later in the spec
and just adds a lot of new concepts people need to absorb.
In particular, I don't think that the first five properties
(AOR through identity) are that relevant here.

S 4:
Having this many use cases doesn't add that much. I would
just delete this section after moving one use case (REFER?)
to the introduction.

S 5:
I didn't find this section that helpful. It seems to me
that the
key points to get across are:

    1. You have one AOR but multiple GRUUs, each of which is
tied
       to a specific UA
    2. You can have multiple GRUUs tied to the same UA.
    3. You can be addressed either by GRUU or AOR, with the
latter
       going to some UA out of control of the addressor.
    4. You (generally) get your GRUUs from your proxy.
    5. There are two types of GRUUs, those which can be
mapped
       back to the AOR (opaque=) and those which can't.

Getting these points across, with a picture would, it seems
to me,
get the job done better than this text. I didn't find
Figure 3
to be that clear, however. Maybe multiple figures?

S 6:

   o  When a GRUU is assigned to an instance ID/AOR pair,
both SIP and
      SIPS GRUUs will be assigned.  Only one will be
returned, but both
      will exist.  The SIPS URI may not always work,
particularly if the
      proxy cannot establish a secure connection to the
client.

What does it mean to have a URI assigned that doesn't work?

   However, forwarding services, such as call forwarding,
SHOULD NOT be
   provided for requests sent to a GRUU.  The intent of the
GRUU is to
   target a specific UA instance, and this is incompatible
with
   forwarding operations.

This seems to me to get into policy. Are you saying that I
can't
have my cell phone forward calls to some other phone just
cause
people call my cell number rather than my generic
"EKR" AOR?

S 8.1.1:

   If the UA instance has obtained multiple GRUUs for
different AORs as
   a result of a registration, it SHOULD use one
corresponding to the
   AOR used to send or receive the request.

Isn't it a security condition for the peer that these
match?

S 12:
Is there any way you can notate the "changed"
headers so it's
easier to see what this specification affects?

Please show the INVITE in message 3 for completeness.

In the subscribe on page 30, you have:

   location lookup on the Request-URI.  It is translated
into the
   contact for that instance, and then proxied to that
contact.  Note
   how the "grid" parameter is maintained, and
the "gruu" parameter is
   no longer present.

This only applies to the URI in the request line, not to the
"To"
line.

   The registrar notices that a different contact,
sip:callee192.0.2.1,
   is already associated with the same instance ID.  It
registers the
   new one too and returns both in the REGISTER response. 
Both have the
   same GRUU.  However, only this new contact (the most
recently
   registered one) will be used by the proxy for population
in the
   target set.  The registrar then generates the following
response:

Why is it a good idea to register both instead of replacing
the
old one? I appreciate this is in Outbound, but I don't much
like
it there either...

S A.2:
The algorithm described here treats encryption as a
black-box
in a way that is potentially severely cryptographically
weak.
In particular, you have:

   In many cases, it will be desirable to construct the GRUU
in such a
   way that it will not be possible, based on inspection of
the URI, to
   determine the Contact URI that the GRUU translates to. 
It may also
   be desirable to construct it so that it will not be
possible to
   determine the instance ID/AOR pair associated with the
GRUU.  Whether
   a GRUU should be constructed with this property is a
local policy
   decision.

   With these rules, it is possible to construct a GRUU
without
   requiring the maintenance of any additional state.  To do
that, the
   URI would be constructed in the following fashion:

      user-part = "GRUU" | BASE64(E(K, (salt |
" " | AOR | " " |
      instance ID)))

   Where E(K,X) represents a suitable encryption function
(such as AES
   with 128-bit keys) with key K applied to data block X,
and the "|"
   operator signifies concatenation.  The single space
(" ") between
   components is used as a delimiter, so that the components
can easily
   be extracted after decryption.  Salt represents a random
string that
   prevents a client from obtaining pairs of known plaintext
and
   ciphertext.  A good choice would be at least 128 bits of
randomness
   in the salt.

You're assuming that you have a cipher that propagates
differences,
but not all ciphers do. For instance, block ciphers in ECB
mode
and stream ciphers (or CTR mode ciphers) do not. It's
nowhere
near specific enough to say "a suitable encryption
function such 
as AES with 128-bit keys" As a second note, it's not
safe to
use stream cipher with the same key repeatedly, which is
what's
implied by this text.

The correct procedure here isn't to use a *salt* but rather
an
IV. Yes, in the case of a block cipher this gets prepended
to the 
data (at least notionally) but in the case of a CTR-mode
cipher
it's used as part of the counter block. 

   Encryption is needed to prevent attacks whereby
   the server is sent requests with fake GRUUs, causing the
server to
   direct requests to any named URI.  Even with encryption,
the proxy
   should validate the user part after decryption.  In
particular, the
   AOR should be managed by the proxy in that domain. 

Encryption doesn't provide this service. If, for instance,
you
used a stream cipher or a block cipher in CTR mode, an
attacker
could still forge new GRUUs with chosen properties based on
a known initial URI/GRUU pair. This is potentially even
possible
in CBC mode depending on how things are laid out. What you
need
here is an integrity check. 

Rather than trying to invent this token format, I would
suggest
you borrow one from an existing document, such as that in
RFC 4507.
Here's some text based on that:

   With these rules, it is possible to construct a GRUU
without
   requiring the maintenance of any additional state. The
   proxy needs to store two randomly chosen secret keys:

   K_e -- used for encryption
   K_m -- used for integrity

   For each new GRUU, the proxy generates a fresh
initialization
   vector (IV) I. It then computes:

   EA = E(K_e, AOR || " " || instance_ID)

   using initialization vector I where || indicates
concatenation.

   The encryption algorithm SHOULD be chosen so that it is
not
   feasible for an attacker two distinguish identical
plaintexts when
   they are encrypted with distinct IVs. The encryption
algorithm
   SHOULD be chosen to provide at least 80 bits of security,
Suitable
   algorithms would include AES in cipher-block-chaining
(CBC) mode
   [1] or counter (CTR) modes [2]. Note that if CTR mode is
used,
   extreme care MUST be taken to ensure that not only are
distinct
   IVs chosen but that the same section of keystream is
never
   reused. 

   Once EA has been computed, the proxy computes:

   HM = MAC(K_m, EA)

   Where HM is a suitable MAC function, such as HMAC-SHA1
[3].

   The GRUU is then constructed as:

   user-part = "GRUU" || BASE64(EA || HM)

   This mechanism uses the user-part of the SIP URI to
convey the
   encrypted AOR and instance ID.  The user-part is used
instead of the
   "opaque" URI parameter because it has the
desired anonymity
   properties.

   The benefit of this mechanism is that a server need not
store
   additional information on mapping a GRUU to its
corresponding
   contact.  The user-part of the GRUU contains the instance
ID and
   AOR.  Assuming that the domain stores registrations in a
database
   indexed by the AOR, the proxy processing the GRUU would
look up the
   AOR, extract the currently registered contacts, and find
the one
   that matches the instance ID encoded in the Request-URI. 
The
   contact whose instance ID is that instance ID is then
used as the
   translated version of the GRUU.  Message integrity is
needed to
   prevent attacks whereby the server is sent requests with
fake
   GRUUs, causing the server to direct requests to any named
URI.

   While this approach has many benefits, it has the
drawback of
   producing somewhat longer GRUUs because of expansion due
to
   the padding and base64 encoding.

[1] National Institute of Standards and Technology,
    Specification for the Advanced Encryption Standard
(AES)"
    FIPS 197.  November 26, 2001.

[2] Housley, R., "Using Advanced Encryption Standard
(AES) Counter
    Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686,
    January 2004.

[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 
Keyed-
    Hashing for Message Authentication", RFC 2104,
February
    1997.

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Comments on draft-ietf-sip-gruu-10

Thread: Comments on draft-ietf-sip-gruu-10