Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 02 Jun 2002 23:33:18 -0400

Comments on this draft:

>   Extensions to the Session Initiation Protocol (SIP) for Asserted
>                     Identity within Trusted Networks
>                   draft-ietf-sip-asserted-identity-00

Based on iesg feedback on the call-auth draft, I suggest you
pre-emptively add "Private" to the beginning.

>  This document describes private extensions to SIP that enable a
>    network of trusted SIP servers to assert the identity of end users or
>    end systems

I seem to recall that the requirements explicitly talk about the
identity of users (calling and called parties), and NOT their
devices/end-systems (the phone can authenticate itself as the phone
using sip...). Its a nit, but one of my big concerns is that we are
clear on WHAT identity is being asserted.

> This
>    document does NOT offer a general privacy or identity model suitable
>    for inter-domain use, 

But it does; can't the trust domain span "domains" in the traditional
DNS sense?

> The means by which the
>    network determines the identity to assert is outside the scope of
>    this document (though it commonly entails some form of
>    authentication).

I thought it was a requirement that the specification clearly define the
means by which identity is authenticated.

>  A key requirement of [5] is that the behavior of all nodes within a
>    given Trust Domain 'T' is known to comply to a certain set of
>    specifications known as 'Spec(T)'.  Spec(T) MUST specify behavior for
>    the following:
> 
>    1.  The manner in which users are authenticated

OK, I think I am confused. I had thought that spec(T) was THIS document,
but perhaps its more of some abstract thing that a domain is aware of
(my apologies if this was extensively discussed - i missed many of the
threads on this subject). I fear the requirements doc might be
conflating the two, since I finished my read of that assuming that this
was the case.

In any case, the list of things spec(T) has to specify belongs in the
requiremetns document, not here, I would think, and certainly not in the
applicability statement.

> For example, a caller that wants to
>    maintain privacy and consequently provides limited information in the
>    SIP From header field will not be identifiable by recipients of the
>    call unless they rely on some other means to discovery the identity
>    of the caller.

s/discovery/discover

However, I think this example doesn't support the claim above. The
outcome described here - that the recipients of the call can't know who
the caller is - is the desired outcome, and not an error. The claim is
that certain combinations that need to be supported, can't be supported.
This is NOT such a combination.

> This document attempts to address this requirement using a very

"this requirement" is a dangling reference here, since the requirement
you are talking about is mentioned two paragraphs above. I suggest "This
document attempts to provide a network asserted identity service...."

>  [5]  Watson, M., "Short term requirements for Network Asserted
>         Identity", draft-ietf-sipping-nai-reqs-01 (work in progress),
>         May 2002.

This is listed as a normative requirement, but its going to be an
informational RFC. I don't believe you can have informational RFCs as
normative dependencies. You should make it an informational reference.

> When a proxy receives a
>    message from a node it does not trust, the proxy MUST authenticate
>    the originator of the message, and use the identity which results
>    from this authentication to insert an appropriate P-Asserted-Identity
>    header field into the message.

This won't work, of course, for a proxy that receives an incoming call
made by a user in a separate domain. You can't mandate that a proxy
authenticate ALL incoming requests, and certainly not all incoming
messages (which then includes responses). I think you mean that a proxy
MAY authenticate the originator...

Furthermore, the word "appropriate" is too vague here. You need to be
more specific. 

Also, shouldn't this bit here mention something about spec(T) - using
the authentication mechanism described there, or something?

> 6. Hints for Multiple Identities

isn't this part of proxy behavior? It should be a subsection of 5.
Indeed, it should probably be towards the beginning of 5, which needs to
lay out a rigorous set of processing steps for a proxy, preferably in
the order they need to be done. Since the hints are used in the
beginning of proxy processing, they belong early on.

Also, I just commented in a separate email that I do not believe we
should reuse P-Asserted-ID for this.

>  Parties who wish to request the removal of P-Asserted-Identity header
>    fields before they are transmitted to an element that is not trusted
>    may add the "id" privacy token to the Privacy header field. 

reference to privacy spec is appropriate here.

> If there is no Privacy header field, the proxy MAY include the P-
>    Asserted-Identity header field or it MAY remove it.

You need to qualify this sentence with "when forwarding the request to
an untrusted element."

> Users will typically want to
>    request "id" privacy when they are challenged for authentication.

This seems to imply that the only time you need to include the Privacy:
id is when you send the request as a result of a 401/407. But, thats not
true. Consider a proxy connected to a user with TLS (which will be the
case frequently in order to establish trust between the user and thr
proxy). The proxy need only challenge the user once; subsequent requests
over the same tls connection are known to be from the same user. Thus,
these rqeuests are not a result of a 401/407, but need to have the
Privacy: id header on them since the proxy can assert an identity.

> If multiple P-Asserted-Identity headers field values are present in a
>    message, and privacy of the P-Asserted-Identity header field is
>    requested, then all instances of the header field values MUST be
>    removed.

add "before forwarding the request to an untrusted entity".

Section 7, as with 6, needs to be split up and the appropriate behavior
relegated to sections on UAC, UAS and proxy behavior.

> The P-Asserted-Identity header field is used among trusted SIP
>    entities (typically intermediaries) to carry the identity of the user
>    sending a SIP message as it was verified by authentication.
> 
>        PAssertedID = "P-Asserted-Identity" HCOLON ( name-addr / addr-spec )

This grammar is not correct. Multiple headers with a single value MUST
be identical to a single header with multiple values. That is, the
following two need to be the same:

P-Asserted-Identity: sip:[email-masked], tel:5551212

and

P-Asserted-Identity: sip:[email-masked]
P-Asserted-Identity: tel:5551212

indeed, no matter which form is used, this is formally referred to as a
"P-Asserted-Identity header field with multiple values". Thus, your BNF
must be:

PAssertedID = "P-Asserted-Identity" HCOLON pid-value *(COMMA pid-value)
pid-value = nameaddr / addr-spec

> There may be zero or one P-Asserted-Identity
>    headers with either a SIP or SIPS URI and in addition there may be
>    zero or one P-Asserted-Identity headers with a tel URL. 

These words are not correct. The proper wording is:

"There may be one or two P-Asserted-Identity values. If there is one
value, it MUST be a sip, sips, or tel URI. If there are two values, one
value MUST be a sip or sips URI, and the other MUST be a tel URL."

>     Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
>         ------------         -----   -----   ---  ---  ---  ---  ---  ---
>         P-Asserted-Identity           adr     -    o    -    o    o    -
> 
> 
>                                              SUB  NOT  REF  INF  UPD  PRA
>                                              ---  ---  ---  ---  ---  ---
>                                               o    o    o    -    -    -

Is there a particular reason that this header is excluded from usage in
INFO, UPDATE, PRACK, REGISTER and ACK? The only one where it doesn't
make sense is CANCEL.

> The presence of this privacy type in
>    a Privacy header field indicates that the user would like the Network
>    Asserted Identity to be kept private with respect to SIP entities
>    outside the Trust Domain or trust federation with which the user
>    authenticated. 

This is the first time the term "trust federation" is introduced. Please
stick to terminology from the requirements document.

> Via header branch parameters are
>    omitted for clarity.

Well, you've included call-ids, cseqs, and even tags. Please do include
the branch IDs so that these are valid requests, else make them have
ONLY the headers relevant to the flow, so its clear that they are not
valid requests. The latter is preferred. 
Section 10.1 should have a ladder diagram.

In 10.1, message F2 is missing a to tag (all responses have them)

In 10.2, there is an extra CRLF in message F3, after max-forwards.

> 13.2 Registration of "id" privacy type for SIP Privacy header
> 
>    Name of privacy type:    id

You need to reference the section of the privacy spec which has defined
this IANA registry. Furthermore, the information provided here must
match, word for word, the request information defined by the privacy
spec. Unfortuantely, it doesn't do that properly yet, but these two docs
need to get aligned on that.

Thanks,
Jonathan R.

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Session Initiation Protocol Working
> Group of the IETF.
> 
>         Title           : Extensions to the Session Initiation Protocol
> (SIP)
>                           for Asserted Identity within Trusted Networks
>         Author(s)       : C. Jennings, J. Peterson, M. Watson
>         Filename        : draft-ietf-sip-asserted-identity-00.txt
>         Pages           : 17
>         Date            : 28-May-02
> 
> This document describes private extensions to SIP that enable a
> network of trusted SIP servers to assert the identity of end users or
> end systems, and the application of existing privacy mechanisms to
> the identity problem.  The use of these extensions is only applicable
> inside an administrative domain with previously agreed-upon policies
> for generation, transport and usage of such information.  This
> document does NOT offer a general privacy or identity model suitable
> for inter-domain use, or use in the Internet at large.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-00.
> txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-sip-asserted-identity-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-sip-asserted-identity-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> 
> Subject:
> Date: Wed, 29 May 2002 12:44:54 -0400
> 
>   ------------------------------------------------------------------------
> 
>    ATT40156.txtName: ATT40156.txt
>                Type: Plain Text (text/plain)
> 
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 11 Jun 2002 15:02:16 +0100

Jonathan,

Sorry, I missed this one from last week.

Just on the relationship between Spec(T), the requirements and this draft.

1) The requirements tell us that our solution can assume a known common
behaviour (aka Spec(T)) for a set of nodes (the Trust Domain), and that we
can assume that some of those nodes know about others and have secure
connections etc. This assumption is designed to allow us to define a
solution which does not use cryptography, but it does not pre-suppose what
the 'common known behaviour' actually is - working out what that behaviour
is is the job of Cullen's draft.

2) The solution (Cullen's draft) describes what has to be included in
Spec(T) in order to make the mechanism work. Some of this is detailed
procedures, and indeed all of Cullen's draft would need to be included in
any working Spec(T). Some of it is open for the Trust Domain to decide, we
just point out that certain things do need to be specified in order for the
header to be meaningful.

3) Spec(T) for a given Trust Domain T fills in the details required by
Cullen's draft, for example the exact manner in which users are
Authenticated. Another Trust Domain, U, might have a different
specification, Spec(U) which specified a different, perhaps more or less
reliable, manner of authentication.

This means that knowing about Cullen's draft is not enough to tell you what
a P-Asserted-Identity header that you receive actually means - in particular
you don't know the authentication procedure used to generate it - but this
is a GOOD THING because you should only attach meaning to a
P-Asserted-Identity header if you really do know all about the Trust Domain
asserting it - i.e. if you really know about what's in Spec(T).

At the end of the day we cannot specify abolutely that P-Asserted-Identity
headers all have some known reliability 'X', so it is better not to even try
and say this (e.g. by specifying a particular authentication scheme in
Cullen's draft). The relability of the data in this header depends on the
particular Trust Domain.

...Mark

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 03 June 2002 04:33
> To: [email-masked]
> Cc: [email-masked]; Jon Peterson; Watson, Mark [MDN05:EP10:EXCH]
> Subject: Re: I-D ACTION:draft-ietf-sip-asserted-identity-00.txt
> 
> 
> Comments on this draft:
> 
> >                                              SUB  NOT  REF  
> INF  UPD  PRA
> >                                              ---  ---  ---  
> ---  ---  ---
> >                                               o    o    o   
>  -    -    -
> >         "FILE 
> /internet-drafts/draft-ietf-sip-asserted-identity-00.txt".
> >