Draft:  draft-ietf-sipping-update-pai-01.txt
Reviewer: Vijay K. Gurbani
Review Date: May 11 2008
Review Deadline: May 12 2008
Status: Initial review

Summary: This draft is on the right track but has open issues, described in the review.

This document extends the semantics of rfc3325 to cover the insertion of (P-Asserted-Id) P-A-I and (P-Preferred-Id) P-P-I in requests other than INVITE as well as in responses.

- This draft uses the notion of trust domains pervasively; as
  such, it will help to define what a "trust domain" is.  This
  should be done in the terminology section, and can be simply
  done by pointing the reader to S2.3 of rfc3324
  (http://tools.ietf.org/html/rfc3324#section-2.3).

- Last sentence of S2, consider replacing "It" with "This
  document".

- S3.1, last paragraph: instead of ambiguously saying "certain
  cipher suite", better simply say "cipher suite of
  RSA_WITH_AES_128_CBC_SHA1"

- S3.2, the second example (last paragraph on page 4) is rather
  ambiguous: "useful to give an early indication to each user
  concerned of the identity of the user to which..."  The
  example is valid enough, however, restating it to be a bit more
  clear may not be a bad idea.  Right now I am not sure whether
  the ID of each forked branch is sent to the B2BUA or the caller
  (who may get confused), and so on.

- S3.6, line 5: better to say "responder" instead of "sender".

- S3.6, first bullet item: does this impact rfc4916?  That is,
  when is it preferable to signify the identity of the responder
  using rfc4916 and when should one use this draft?  Some text
  clarifying this would be good.

- S3.6, third bullet item: s/would give/would/

- S3.6, page 6 second paragarph: s/that talk only about/only mention

- S4: s/This updates/This draft updates

- S4.1.2: s/value freely/value unconditionally

- S5: Simply reword to say "This draft requires no IANA actions."

- S6: s/specified inRFC/specified in RFC

- S6: I must admit that the whole idea of a UAC inserting a P-A-I
  (or P-P-I) in a request -- and a UAS doing the same in a response --
  seems counter to what we have done so far.  Traditionally, we
  have not trusted user-inserted identities, but this draft seems
  to relax this bound.  Does doing so open up any new security
  concerns?  One, what would a proxy do if it receives a request
  with a P-A-I that does not match what *it* would have inserted
  if it was to authenticate this request?  I don't think this is
  discussed in S4.2, is it?  Same concern for a UA-inserted P-A-I
  in a response.

  Second, is there some sort of user authentication that happens
  between a physical user and his/her device before the device
  inserts a P-A-I?  In other words, what happens if malicious
  Eve makes a call from Alice's phone, pretending to be Alice.
  I realize that in today's PSTN, I can go and pick up anyone's
  phone and make a call; the ramifications of that call will fall
  on the identity of whoever possesses the number associated
  with that phone.  Similarly, once I authenticate myself to my
  TLS certificate for email and walk away from my terminal, anyone
  can come and send email purportedly from me.  However, at least
  there is some authentication done in the TLS certificate case.
  It seems that if UAs are to insert the identities, then they are
  free to do so without authenticating the user on the first
  attempt.  Is that indeed the case?  If so, just state that in the
  draft.

  Clearly, we do not want the UA to constantly ask someone for a
  password before making every call.  Some ways to mitigate that
  is to use the same technique Yahoo! email does: it periodically
  (randomly) asks you to re-authenticate yourself.