Subject: [Sipping] Working Group Last Call -- draft-ietf-sipping-nai-reqs

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 15:41:45 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 15:15:13 -0400

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? 

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?

>  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
[email-masked], but know that my home phone number is tel:XXX as a
result of some administrative process? BIG difference.

> 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". 

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"

> 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. 

> 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". 

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.

> 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.

> 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.

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

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

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 31 May 2002 14:34:55 -0500

> language above, like "Each party SHOULD NOT have more than one NAI"

I think it means that if the UA provides an identity which is NOT
reasserted be the trust domain, then the trust domain MUST remove that
identity. A message may at most assert one identity of type sip/sips and
one of type tel. I certainly hope it does not restrict the range of
possible assertions to a single identity per USER, just one per message.

Suggested rewording:

	Each message shall assert at most one "sip" or "sips" identity
and one "tel" identity.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 31 May 2002 12:46:35 -0700 (Pacific Daylight Time)

> "NOT" is not an rfc2119 term, and SHOULD NOT be capitalized.

NOT is not an RFC2119 term, but it MAY be capitalized where extra
emphasis or attention is needed.  For example, the applicability statement
in call-auth contains a NOT which was suggested by our Area Director.  I
wrote the specific language, and Flemming accepted my proposed wording.

I STRONGLY encourage such usage in applicability statements.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 16:31:32 -0400

> I STRONGLY encourage such usage in applicability statements.

OK. Or is it "ok"? Hmm.

-Jonathan R.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 31 May 2002 16:52:56 -0400

>* A trusts C, but A does not trust B

This seems to contradict putting A and B inside the same dotted 
line.  Should there be two overlapping dotted boxes, one with A+C and one 
with C+B?

>* B does not trust F, F does not trust

Mike H.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 16:58:42 -0400

> line.  Should there be two overlapping dotted boxes, one with A+C and

My reading of the definitions was that trust domain referred to the set
of elements which all shared the same spec(T). That is NOT the same as
"A trusts B", which implies a secure relationship between A and B, in
addition to A knowing that B is part of the trust domain. Thus, even
though A and B are part of the same trust domain (since they both
implement spec(T)), since there is no direct connection, A doesn't trust
B.

-Jonathan R.