Subject: [Sipping] Initial WG review of draft-ietf-sipping-update-pai-01.txt

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 11 May 2008 20:18:42 -0500

John: Here is my WGLC review of draft-ietf-sipping-update-pai-01.txt.

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.

That's it.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sipping mailing list  https://www.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: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 10:04:35 +0100

Vijay,

Thanks for reviewing the document. See my responses below.

John 

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 12 May 2008 02:19
> To: Elwell, John
> Cc: [email-masked]; Mary Barnes; Gonzalo Camarillo
> Subject: Initial WG review of draft-ietf-sipping-update-pai-01.txt
> 
[JRE] Done. Likewise Spec(T).

> - Last sentence of S2, consider replacing "It" with "This
[JRE] Done.

>   RSA_WITH_AES_128_CBC_SHA1"
[JRE] On the contrary, I received a different comment saying that it
should be in accordance with Spec(T), which does not limit it even to
TLS. So I have drafted the following for the next version: "...nodes
within a Trust Domain must behave in accordance with Spec(T)".

>   (who may get confused), and so on.
[JRE] But the following sentence says "This can be achieved by the B2BUA
sending an UPDATE request with a P-Asserted-Identity header field on the
dialogs concerned." So in my opinion it is clear that the B2BUA sends
it. However, I have inserted the sentence "In other words, provide the
new calling UA with the identity of the new called user and provide the
new called UA(s) with the identity of the new calling user." to try to
give greater clarity.

> - S3.6, line 5: better to say "responder" instead of "sender".
[JRE] Done.

>   clarifying this would be good.
[JRE] The next paragraph already discusses including PAI in a response
to a dialog-forming request versus sending it in a mid-dialog request in
the reverse direction. However, it does not explicitly mention RFC 4916.
I have so far avoided any mention of SIP Identity in this document, so I
am not totally convinced of the necessasity. I can add a note, if you
think it is worthwhile. The note would say "<t>Note that when the
authenticated identity of the connected user is to be provided using the
From and Identity header fields (as opposed to providing asserted
identity using the P-Asserted-Identity header field), <xref
target="RFC4916"/> requires this to be done in a mid-dialog request
(e.g., UPDATE) in the reverse direction. This is because the Identity
header field is defined only for use in requests.</t>". RFC 4916 would
just be an informative reference.

> - S3.6, third bullet item: s/would give/would/
[JRE] Done.

> - S3.6, page 6 second paragarph: s/that talk only about/only mention
[JRE] Done.

> - S4: s/This updates/This draft updates
[JRE] Changed to "This document updates".

> - S4.1.2: s/value freely/value unconditionally
[JRE] I do not like "unconditionally". I have changed to "internally":
"<t>If a UA is part of the Trust Domain from which it received a
response containing a P-Asserted-Identity header field, then it can use
the value internally but it MUST ensure that it does not forward the
information to any element that is not part of the Trust Domain if the
responding user has requested that asserted identity information be kept
private.</t>"

> - S5: Simply reword to say "This draft requires no IANA actions."
[JRE] Done.

> - S6: s/specified inRFC/specified in RFC
[JRE] I cannot locate this one.

>   discussed in S4.2, is it?  Same concern for a UA-inserted P-A-I
[JRE] The important point is that PAI will be trusted only if it comes
from within the Trust Domain, so it doesn't really matter whether it is
a UA or a proxy that sends it, provided it has been authenticated in
accordance with Spec(T) (e.g., TLS). So I don't think we are really
relaxing anything - more a clarification. I have added to 4.2.1 the
following:
"<t>Note that this implies that the proxy must have authenticated the
sender of the request in accordance with the Spec(T) in force for the
Trust Domain and determined that the sender is indeed part of the Trust
Domain.</t>"

>   attempt.  Is that indeed the case?  If so, just state that in the
[JRE] The relaxation or clarification concerning UAs sending PAI is not
intended for UAs under user control, typically. It is intended more for
things like PSTN gateways, media servers, etc., that are indeed trusted
to some extent. A typical desk phone, mobile phone, etc. would not
normally be considered part of the Trust Domain, and therefore would not
be able to send PAI (or if it did, the proxy would not accept it).
Instead, the proxy would normally require digest authentication, and on
that basis would insert PAI on the UA's behalf. The UA could, of course,
use PPI.

I will add the following sentence to section 6: "Typically a UA under
the control of an individual user (such as a desk phone or mobile phone)
should not be considered part of a Trust Domain."

>   (randomly) asks you to re-authenticate yourself.
[JRE] The problem of a UA providing authentication on the user's behalf
(e.g., digest authentication) is a general problem with SIP UAs, and
something that has to be left to the UA to solve. Some UAs might require
the user to provide authentication using a PIN or password, and may
require this as a 1-off, on a per call basis, or somewhere between the
two. Perhaps this will be configurable, so that the user can select an
option appropriate to the environment (e.g., a locked room versus a
public room). However, this is all outside the scope of the present
draft.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 12 May 2008 17:46:38 -0500

> Thanks for reviewing the document. See my responses below.

John: Thank you for your attention to the comments.  Some
further discussion points inline.

> within a Trust Domain must behave in accordance with Spec(T)".

This Spec(T) is fun!  It does everything ;-)

> new called UA(s) with the identity of the new calling user." to try to

Ummm...let me see if I can take another stab.  The scenario you
are describing is approximated by the following figure:

                       +----> UA1
   UAC ----> B2BUA ----+----> UA2
                       +----> UA3

UAC has established a session with B2BUA (and is probably on
hold); B2BUA has forked to UA{1,2,3} (either the B2BUA forked
the call or a downstream intermediary proxy did.)  Now,
as early dialogs are established by UA{1,2,3}, is the UAC
notified of the identity associated with *all* these early
dialogs?  Or is it notified of only the identity of the UA
that eventually accepted the call?

> I have so far avoided any mention of SIP Identity in this document, 

Any specific reason why?  Implementors that may be aware of it will
out of necessity think of the overlap.

> I can add a note, if you think it is worthwhile. The note would say 
[...]

Instead of adding a note to the first bullet item as you suggest,
it is easier to just mention rfc4916 in the next paragraph.  In
other words:

OLD:
    In the case of a request that results in the formation of a dialog, a
    mid-dialog request (e.g., UPDATE) in the reverse direction can
    provide the identity of the user at the destination end of that
    dialog, and therefore the need to include asserted identity in a
    response to the dialog-forming request is debatable.

NEW:
    In the case of a request that results in the formation of a dialog,
    a mid-dialog request (e.g., UPDATE) in the reverse direction can
    provide the identity of the user at the destination end of that
    dialog (see [RFC4916]).  Hence, the need to include asserted
    identity in a response to the dialog-forming request is
    debatable and best used only in a Trust Domain.

> [JRE] I cannot locate this one.

Never mind; that was me trying to squint.

>>   seems counter to what we have done so far.  [...]
> [JRE] [...] So I don't think we are really relaxing anything - 
> more a clarification. I have added to 4.2.1 the following:

OK.

>>   inserts a P-A-I?  [...]
> to some extent. [...]
> would not be considered part of a Trust Domain." 

OK; that clarifies many things.  Please add it.

> something that has to be left to the UA to solve. [...]

All that does not matter anymore based on the clarification you
provided about "UA under the control of an individual user" not
being considered part of the Trust Domain.

That's it.  All other edits look good.  Thanks.

Ciao.

- vijay

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 May 2008 07:25:03 +0100

Vijay,

My responses below.

John 

> Sent: 12 May 2008 23:47
> Subject: Re: Initial WG review of draft-ietf-sipping-update-pai-01.txt
> 
> Elwell, John wrote:
> > Vijay,
> > 
[JRE] I guess the way a B2BUA might do it is to send to the UAC the AoR
to which the request is now targeted. This would work fine if UA1, UA2
and UA3 are all contacts for the same AoR, which would normally be the
case. Of course, if one of them was a retarget to some other AoR and
that one happened to answer, an updated PAI would need to be sent to the
UAC at the time of answer.

> out of necessity think of the overlap.
[JRE] In fact I decided to add something. So in the Introduction it now
says: "<t>This document does not alter the fact that the asserted
identity mechanism has limited applicability, i.e., within a Trust
Domain. For general applicability, including operation outside a Trust
Domain (e.g., over the public Internet) or between different Trust
Domains, a different mechanism is needed. RFC 4474 <xref
target=RFC4474"/> specifies the Identity header field, in conjunction
with the From header field, for providing authenticated identity in such
circumstances.</t>"

>     debatable and best used only in a Trust Domain.
[JRE] In fact I had already decided to go ahead with the note and I had
drafted the following, to appear after the existing paragraph discussing
response versus UPDATE. I hope this will satisfy your concern:
"<t>Note that when the authenticated identity of the connected user is
to be provided using the From and Identity header fields (as opposed to
providing asserted identity using the P-Asserted-Identity header field),
RFC 4916 <xref target="RFC4916"/> requires this to be done in a
mid-dialog request (e.g., UPDATE) in the reverse direction. This is
because the Identity header field is defined only for use in
requests.</t>"

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 13 May 2008 08:17:11 -0500

> UAC at the time of answer.

John: These were the kind of ambiguities I was referring to in
my initial email regarding tightening up the example description.
But regardless, we do not have to specify how a B2BUA does 3PCC
in this document; so I will trust your good judgment on what you
think will best word the example description for the reader.

> says: [...]

Perfect; thanks.

[...]

Sure; this is good.  My point was that a reader who was aware of
rfc4916 will be hopelessly despondent if we do not discuss the
intersection of sipping-update-pai with rfc4916.  The text you
now have is good.

Thanks,

- vijay

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 May 2008 13:04:54 +0300

Hi Vijay,

thanks for your review!

Just a clarification: this is an initial review, not a WGLC review. The 
WGLC for this document, as currently planned, will take place in September.

Cheers,

Gonzalo