Subject: [Simple] Review of draft-ietf-simple-view-sharing-01

From: Richard Barnes <[email-masked]>
Date: Mon, 08 Sep 2008 14:45:42 -0400

========================================================================
Document: draft-ietf-simple-view-sharing-01
Reviewer: Richard L. Barnes, BBN Technologies
Date: 5 September 2008
========================================================================

General comments
========================================================================

1. A seemingly minor but important point: The document is 
unclearthroughout on whether this mechanism facilitates sharing between 
"systems" or "domains".  The latter is more consistent with Figure 1, 
and seems like what you're actually going for.  In particular, if the 
RLS is associated with a domain, then it might be possible to avoid 
manual provisioning (see 6. below)

2. The document does a good job of addressing the risks that the Serving 
Domain is exposed to through view sharing.  However, it doesn't address 
the privacy risks that the *presentity* is exposed to.  The Watching 
Domain is now explicitly responsible for applying the privacy policies 
that the user has set (providing different views to different watchers), 
so the presentity now has to trust the Watching Domain to perform that 
operation as opposed to just passing through NOTIFYs.  The risk is that 
the Watching Domain fails to apply the Rule Determination Algorithm (as 
required in 3.2.2), and presence info fromone view leaks into others.
   You can tell a similar story here to the one you tell for ACLs inthe 
Security Considerations: Without view sharing, the Watcher already has 
access to all that presence information, so if it were malicious, it 
could already leak information between views.  Thus the only real risk 
is non-compliance, which you can't fix in a standard.  The only 
recommendation that seems necessary here is another reminder to the RLS 
to reinforce the importance of the rules determination algorithm being 
done correctly.

3. It would be nice to discuss how view sharing interacts with S/MIME 
protected presence documents.  For signed objects (that aren't 
encrypted), the usage is probably pretty much the same, except that the 
PA won't be able to modify the presence documents (unless it's the 
signer).  For enveloped/encrypted objects, there's some interaction 
between the set of authorized watchers and the set of keys that can be 
used to decrypt the object.

4. It's not clear to me why it's more critical to use TLS with view 
sharing than otherwise.  As you point out in the Security 
Considerations, no more information is exposed here than with normal SIP 
events.  The risks of identity spoofing and interception are the same. 
It might even be less so if the peers are using direct links to each 
other (as in layer-2 peering federations).

5. The document doesn't specify whether or not a single ACL can contain 
members from many domains.  From a privacy perspective, my preference 
would be to specify that within a single ACL,
-- All members MUST have the same domain
-- That domain MUST be the domain of the RLS

6. Obviously, the requirement for "explicit provisioning" of trusted 
domains is kind of a turn-off (for scalability, dynamic extension 
oftrusted enclaves, etc.).  It seems like the critical distinction 
you're trying to enforce with this requirement is to separate an RLS 
from a watcher, where an RLS is the entity authorized -- by both domains 
-- to see all presence transactions between the two domains, and the 
watcher is only authorized (by either domain) to see its own 
transactions.  Is there a mechanism other than manual provisioning to 
make this distinction?   It seems like the RLS is something that might 
get advertised in the DNS, for example.  Assuming that (1) the PA 
constrains view-sharing based on the domain of the (supposed) RLS 
matching an RLS in the DNS and (2) the PA only issues ACLs in which all 
members are from the same domain (see above), then the privacy risks 
would be eliminated.  A request from a non-view-sharing domain (as in 
the current example attack) wouldn't come from an RLS, and an attacker 
that creates his own domain/RLS would only get information for his fake 
domain.

7. This document claims in the Abstract and the introduction to be an 
extension to the general SIP events framework.  However, the entire 
introduction is presence-centric, and many of the sections that could be 
general use presence-specific terminology (e.g., S3.2.2 and S4; see 
comments below).  It should be made clearer which parts are 
presence-specific, which are more general.

8. The document should clarify whether it is allowable for a PA to 
initiate the use of view sharing?  For example, could you have a PA that 
only supports view sharing, so that it responds with "Required: 
view-share", whether or not the SUBSCRIBE asked for it?  It may be best 
to forbid this, since it strengthens the asymmetry discussed in section 
2 (PA decides, RLS pays computational burden).

Specific comments
========================================================================

S2
    Depending on the level of trust, the mechanism trades off inter-
    domain messaging traffic for increased processing load in the RLS to
    handle the ACL documents.

This raised a red flag for me at first, since the load on the RLS is 
determined by what the PA decides to do.  However, this asymmetry is not 
so bad because the Serving Domain has to give up potentially sensitive 
information in order to incur increased processing in the Watching 
Domain (and presumably, the Watching Domain has to ask for this, see S4 
below).

It would also be helpful to the reader here to have a brief description 
of what the logical structure of an ACL looks like, since that matters a 
lot for sections 3 and 4.

S3
    This section defines the procedures that are to be followed by the
    RLS.  It is important to note that, even though this specification
    defines an extension to the SIP events framework, that extension is
    only useful for the back-end subscriptions generated by an RLS.

I found the ordering of this section confusing.  I would suggest 
re-organizing according to the temporal order of things, in the 
following way:
3.1.1: Current S3.1.3, Determine whether a suitable subscription exists
3.1.2: Current S3.1.2, Establishing a back-end subscription
(Current 3.1.1 should be folded into 3.1.2, since it deals with how 
back-end subscription is sent)

S3.1.2
    Note that it is possible that two watchers, in a short period of
    time, both subscribe to their resource lists, both of which include
    presentity P.

Might it be simpler to RECOMMEND these back-end transactions be done 
serially?

S3.1.3
    For each ACL Ai in the current ACL list, the RLS performs the rule
    determination algorithm of Section 5.4 to compute the rule ID R for
    the watcher W.

Since the rule determination algorithm takes an ACL list as an input, 
shouldn't this say that the RLS performs the rule determination 
algorithm for W and the current ACL list for the presentity?

S3.1.2
    o  If R is null, it means that the ACL doesn't specify the view ...

Change to "If R is null, it means that no ACL in the list specifies the 
view..."

S3.1.2
       The RLS SHOULD NOT perform
       another back-end subscription, and must act as if it had created a
       back-end subscription which was rejected.

Why is this a SHOULD and not a MUST? (Likewise for the subsequent bullet.)

S3.2.1
    If the contents of the NOTIFY are of type "application/aclinfo+xml",
    the subscriber processes the body as described here.

This is really minor, but given that these aren't the only ACLs around, 
I would prefer a slightly more specific name, e.g. 
"application/view-sharing-aclinfo+xml"

S3.2.1
    The serving domain can change policies at any time.  When it does, it
    sends an updated ACL on one or more subscriptions.  The RLS MUST
    store this ACL.

Do you mean for this ACL to be simply stored, or to replace the old ACL? 
  (Not a huge issue because the rule determination algorithm picks the 
newest.)

S3.2.1
    Furthermore, if there are now two back-end subscriptions j1 and j2
    for which Aj1 = Aj2, the RLS SHOULD terminate one of those two
    subscriptions.

The terms "Aj1" and "Aj2" haven't been defined.  Suggest replacing "for 
which Aj1 = Aj2" with "with equivalent ACLs".

S3.2.2
    If the contents of the NOTIFY is a presence document, the RLS follows
    the procedures defined here.

The details of this section don't seem to have anything in particular to 
do with presence.  Perhaps this could be re-cast in terms of 
notifications of event state in general.

S4
4.  Presence Agent Behavior

The terminology used in this section could better reflect the generality 
of this mechanism.  Perhaps use the terms "State Agent" from RFC 3265.

S4
    When a presence agent receives a SUBSCRIBE request containing a
    Supported header with the value "view-share", and it wishes to
    utilize view sharing for this subscription, it follows the procedures
    defined here.

Is it allowable for a PA to initiate the use of view sharing?  For 
example, could you have a PA that only supports view sharing, so that it 
responds with "Required: view-share", whether or not the SUBSCRIBE asked 
for it?  It may be best to forbid this, since it strengthens the 
asymmetry discussed in section 2 (PA decides, RLS pays computational 
burden).

S4.1
    First, the presence agent MUST have received the SUBSCRIBE request
    over a mutually authenticated TLS connection.  If it had not, view
    sharing cannot be utilized for this subscription.

It's not clear to me why it's more to authenticate SUBSCRIBE requests 
here than in the general case.  As you've argued in the Security 
Considerations, this extension doesn't grant any more information to the 
Watching Domain than was already accessible.  So the risk due to a fake 
RLS with this extension is the same as before.

S4.2
    If an ACL and a presence document are to be delivered, they MUST be
    delivered in a separate NOTIFY request...

Change "a separate NOTIFY request" to "separate NOTIFY requests"

S4.3
    o  There is more than one subscription from the watching domain to
       this presentity with the same view, but the User-Agent header
       field in the request differs between them.

Should this refer to the "sip-instance" parameter instead?  (Likewise in 
S4.5)

S5.1
    This contains the list of rules defined by the ACL.  Each rule is
    represented by the <rule> element.

Seems like "<view>" would be a more appropriate tag name, since there 
are no actual rule semantics here, just an identifier for a view of the 
events.

S5.1
    If two URI are present within <member> elements within the same
    <rule>, it represents a contract by the presence server that both
    users MUST get the same view.  Formally, if the presence server were
    to receive a subscription from each watcher, both subscriptions would
    be accepted or both would be rejected, and if accepted, each
    subscription would receive semantically identical presence documents
    at approximately the same time.

This is the very first time that the term "view" is defined in the scope 
of this document.  It should be closer to the beginning, say a paragraph 
in the introduction of the following character:
"
Frequently, several watchers served by an RLS will receive the same 
"view" of events: If the presence server were to receive a subscription 
from each watcher, both subscriptions would be accepted or both would be 
rejected, and if accepted, each subscription would receive semantically 
identical presence documents at approximately the same time.
"
Also, "indication" or "statement" would be a better word than "contract".

S5.4
    it is possible that inconsistent ACL documents exist.  In that case,
    R is assigned the value Ri from the ACL Ai which is the most recently
    received amonst all ACL.

Change "amonst all ACL" to "amongst all ACLs".

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple