[Sipping] Initial WG review of draft-ietf-sipping-update-pai-01.txt
"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Mon, 12 May 2008 01:18 UTC
Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81103A67FE; Sun, 11 May 2008 18:18:56 -0700 (PDT)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBEA3A67FE for <sipping@core3.amsl.com>; Sun, 11 May 2008 18:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPNRiKMbXX9F for <sipping@core3.amsl.com>; Sun, 11 May 2008 18:18:53 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 8D02F3A6774 for <sipping@ietf.org>; Sun, 11 May 2008 18:18:53 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m4C1IhmU015719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 May 2008 20:18:43 -0500 (CDT)
Received: from [135.244.35.1] (vkg.lra.lucent.com [135.244.35.1]) by umail.lucent.com (8.13.8/TPES) with ESMTP id m4C1IepI010368; Sun, 11 May 2008 20:18:41 -0500 (CDT)
Message-ID: <48279AF2.7020500@alcatel-lucent.com>
Date: Sun, 11 May 2008 20:18:42 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: john.elwell@siemens.com
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Cc: sipping@ietf.org, Mary Barnes <mary.barnes@nortel.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [Sipping] Initial WG review of draft-ietf-sipping-update-pai-01.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Initial WG review of draft-ietf-sipping… Vijay K. Gurbani
- Re: [Sipping] Initial WG review of draft-ietf-sip… Elwell, John
- Re: [Sipping] Initial WG review of draft-ietf-sip… Vijay K. Gurbani
- Re: [Sipping] Initial WG review of draft-ietf-sip… Elwell, John
- Re: [Sipping] Initial WG review of draft-ietf-sip… Vijay K. Gurbani
- Re: [Sipping] Initial WG review of draft-ietf-sip… Gonzalo Camarillo