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

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail], 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.


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

_______________________________________________
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