RE: [Sipping] Working Group Last Call -- draft-ietf-sipping-nai-r eqs

["Mark Watson" <[e-mail]>]

Jonathan,

Thanks for your comments - see notes below...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: 31 May 2002 20:15
> To: Dean Willis
> Cc: [e-mail]; Watson, Mark [MDN05:EP10:EXCH]; [e-mail];
> Jon Peterson ([e-mail]); [e-mail]
> Subject: Re: [Sipping] Working Group Last Call --
> draft-ietf-sipping-nai-reqs
> 
> 
> Comments:
> 
> > An Identity, for the purposes of this draft, is a URI, and 
> optionally 
> >                   a Display Name. The URI MUST be 
> meaningful to the domain identified 
> >                   in the URI when used as a SIP Request-URI. 
> 
> This is a vague definition. What is meaningful? That it routes to the
> user? That it is resolvable based on draft-ietf-sip-srv? 
> 

Less vague suggestions gratefully accepted! The intention was to rule out
URIs which the domain identified in the URI would not recognise - i.e. to
rule out use of URIs which if used as a request-URI in a request and sent to
that domain would just result in some default rejection. The problem with
stating it formally is that the process that the domain uses to process the
request is a local policy/service/implentation matter - it may be that the
first proxy in the domian obtains some called-user-specific script based on
the URI and runs this, possibly still resulting in a rejection.

At the end of the day, what it means for a domain to 'recognise' a URI is
probably not something we can define completely formally, so this is a
'soft' requirement.

Would it make sense to talk about 'routing to the user/user's service logic'
?

> Also, the text explicitly mentions a domain in the URI, which 
> would rule
> out a tel URL. Is that intentional? I doubt it, given that tel URL is
> mentioned later on?
> 

Good point. I will re-word.

> >  A Network Asserted Identity is an identity derived by a 
> SIP network 
> >                   entity as a result of an authentication process. 
> 
> I think this is a slippery definition when the identity is a tel URL.
> When an NAI contains a tel URL, does that imply that the trust domain
> owns that number, and has validated through digest, for example, that
> the user is the one that was given the number by the trust domain? Or,
> does it imply that the trust domain might not own the number (for
> example, its my home phone number), and they have 
> authenticated that I'm
> [e-mail], but know that my home phone number is 
> tel:XXX as a
> result of some administrative process? BIG difference.
> 

Yes. It should be the former. The latter takes us into 'Network Asserted
Reply-to' territory which we agreed we did not want to go into.

I think if I tidy up the wording in the definition of Identity with respect
to tel URIs then this can be made clear.

> > It shall be possible for a UA to provide a preferred 
> identity to the 
> >                   network intermediary, which MAY be used 
> to inform the generation of 
> >                   the Network Asserted Identity according 
> to the policies of the Trust 
> >                   Domain. 
> 
> s/shall/SHALL
> 
> > If a node, A, within the Trust Domain, is trusted by a node, B, 
> >                   outside the Trust Domain, then it shall 
> be possible for A to securely 
> >                   send a Network Asserted Identity to B. 
> 
> I'd like to temper this with the qualifier "if allowed by the privacy
> policies of the user that has been identified, and the trust domain". 
> 

Your proposed qualifier is correct, but I had tried to separate the
requirements for the capability to transfer the NAI from those for the
(privacy-related) cicumstances in which it is allowed to do this.

The statement you quote is an enabling requirement on the mechanism, not on
the nodes - i.e. it means 'the mechanism specified as a result of these
requirements shall include a capability for nodes to send info from A to
B...'. It does not imply an unqualified ability for A to *use* that
capability in any circumstances.

I don't have a big problem adding the qualifier if you still want it,
though.

> The following two requirements (on hints) appear to be inconsistent:
> 
> >  It shall be possible for a UA to provide a preferred 
> identity to the 
> >                   network intermediary, which MAY be used 
> to inform the generation of 
> >                   the Network Asserted Identity according 
> to the policies of the Trust 
> >                   Domain. 
> 
> and:
> 
> > Each party shall have at most one Network Asserted Identity. 
> 
> 
> Perhaps you mean that a message can't carry more than one 
> identity, even
> though the user may have more than one? In any case, you need strong
> language above, like "Each party SHOULD NOT have more than one NAI"
> 

Agreed - I think there were some other mails on this which cleared it up.

> > The means by which any privacy requirements in respect of 
> the Network 
> >                   Asserted Identity are determined are 
> outside the scope of this draft. 
> 
> "in respect" doesn't seem to belong in the sentence above. 
> 

ok.
 
> > It shall be possible to indicate that a Network Asserted 
> Identity is 
> >                   subject to a privacy requirement which 
> prevents it being passed to 
> >                   other users. 
> 
> 
> possible for whom to indicate to whom where? I assume you 
> mean "It MUST
> be possible for the orignator of a message to indicate to the trusted
> domain that its network asserted identity is subject to a privacy
> requirement which prevents it from being passed to entities outside of
> the trust domain". 
> 

I meant that whenever a NAI is passed from one node to another, it must be
possible to accompany that NAI with an indication that it is subject to a
privacy requirement ... etc.

This applies when NAI is passed around within the Trust Domain as well as
when passed from outside the domain to the inside.

> Note that I have explicitly used MUST strength, and explicitly not
> limited the scope to users.
> 
> > It shall be possible to indicate that the user has 
> requested that the 
> >                   Network Asserted Identity be not passed 
> to other users. 
> 
> If there is some subtle difference between this and the previous one I
> have missed it.

The semantics of the first indication (1) are that the NAI cannot be passed
outside the Trust Domain, but there is no information about *why*, it is
just an instruction to the subsequent node.

The semantics of the second indication (2) are that the user has requested
privacy. *One* consequence of this is that the NAI cannot be passed outside
the Trust Domain, but there are others (you requested an example in your
next comment - see below).

So, certainly (2) implies (1), but *in principle* (1) could be present due
to some local Trust Domain policies, without (2). There are some words in
Cullen's draft which strongly discourage this case, and in particular point
out that if you know the user's privacy preference (either way) then you
MUST NOT override this. Further, knowing the user's privacy preference is a
GOOD THING, so Trust Domains should ensure that all their users have the
ability to express this (e.g. in the form of the 'id' privacy service).

In these circumstances we get (1) iff (2), and this is where we want to be.

Nevertheless, I know of Trust Domains which will need cases where (1) does
not imply (2). The distinction can be implemented without additional
protocol elements, by appropriate Trust Domain policies (in Spec(T)), as
described in Cullen's draft.


> 
> > Note that æanonymityÆ requests from users or subscribers may well 
> >                   require functionality in addition to the 
> above handling of Network 
> >                   Asserted Identities. Such additional 
> functionality is out of the 
> >                   scope of this document. 
> 
> I know what you mean, but an example would be helpful.
> 

OK - suggest removal of Via headers.

> > 8. Next steps 
> >                    
> >                   It is has been agreed to adopt 
> draft-jennings-sipping-nai-00 [2] as a 
> >                   working group item to implement the 
> requirements of this draft. 
> 
> This section should be removed in preparation for going to RFC.
> 
> > The requirements in this draft are NOT intended to result in a 
> >                   mechanism with general applicability 
> between arbitrary hosts on the 
> >                   Internet. 
> 
> "NOT" is not an rfc2119 term, and SHOULD NOT be capitalized.
> 
> > Such devices may be hosts on the Internet.
> 
> To my knowledge, all things we talk about in the sip and 
> sipping groups
> are hosts on the internet, so this is a zero entropy statement.
> 
> 
> some additional comments:
> 
> you need to explicitly define spec(T). You never actually state that
> spec(T) is a specification compliant to the requirements in this
> document, and you need to.
> 

OK, I will check this. The definition of a Trust Domain (in general) does
not need to define Spec(T). You can imagine Trust Domains for other purposes
that NAI where the contents of Spec(T) are very different. A definition of
Spec(T) is needed to make a particular mechanism (in our case NAI) *work*,
and so I would see the definition of Spec(T), or at least a description of
the things that Spec(T) MUST specify, as being part of the actual mechanism,
rather than as part of the requirements for the mechanism.

The *requirements* document needs to state that it is OK for the mechanism
to be based on the Trust Domain concept, and say what that concept is. This
aspect of the reqirements allows us to define a solution which is not based
on cryptography.


> A picture illustrating the relationships would be great. Here 
> is what I
> had in mind:
> 
>       Please view in a fixed-width font such as Courier.
> 
> 
> 
>                                      +------+
>                                      |      |
>                                      |  F   |
>                                      |      |
>                                      +------+
>                                          x
>            ..............................x.........
>            .                             x        .
>            .    +------+             +------+     .    +------+
>            .    |      |             |      |     .    |      |
>            .    |  A   |             |  B   |-----.----|  E   |
>            .    |      |             |      |     .    |      |
>            .    +------+             +------+     .    +------+
>            .       \\                   /         .
>            .         \\    +------+   //          .
>            .           \\  |      | //            .
>            .             \ |  C   |/              .
>            .               |      |               .
>            .               +------+               .
>            .                   |      Trust Domain.
>            ........................................
>                                |
>                                |
>                                |
>                            +------+
>                            |      |
>                            |  D   |
>                            |      |
>                            +------+
> 
> 
> 
> 
>        xxxxxx   Insecure connection
>        ------   Secure connection
> 
>        ......
>        .    .All boxes within the dotted line
>        ......are part of the same trust domain
> 
> 
> With statements like:
> 
> * A, B and C are part of the same trust domain
> * A trusts C, but A does not trust B
> * since E knows that B is inside of the trust domain, E
> trusts B, but B does not trust E
> * B does not trust F, F does not trust B
> 
> 

OK. Looks good to me.

> 
> Otherwise, looks pretty good. Formatting is odd, and there were random
> characters in there that didn't seem to display properly.
> 

I blame MS Word :-) Will convert to XML, time permitting.

> -Jonathan R.
> 
> 
> Dean Willis wrote:
> > 
> > We need to do a very fast last call on the network-asserted-identity
> > requirements draft.
> > 
> > Please submit final comments to the list and draft editor 
> IMMEDIATELY.
> > 
> > Draft available from:
> > 
> > 
http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-nai-reqs-01.t
> xt
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nai-reqs-01.txt
> 
> --
> Dean
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[e-mail]                 FAX: [phone]
http://www.jdrosen.net                  PH:  [phone]
http://www.dynamicsoft.com