From iesg-secretary@ietf.org Thu Jan 2 09:25:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B5B1ADFE5; Thu, 2 Jan 2014 09:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tgc6Efi1MSd; Thu, 2 Jan 2014 09:25:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C611AE313; Thu, 2 Jan 2014 09:25:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102172525.16629.39223.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 09:25:25 -0800 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Document Action: 'Session Initiation Protocol (SIP) History-Info Header Call Flow Examples' to Informational RFC (draft-ietf-sipcore-rfc4244bis-callflows-08.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 17:25:29 -0000 The IESG has approved the following document: - 'Session Initiation Protocol (SIP) History-Info Header Call Flow Examples' (draft-ietf-sipcore-rfc4244bis-callflows-08.txt) as Informational RFC This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows/ Technical Summary This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. Working Group Summary There was considerable debate about the placement of these call flows: all within the bis draft, all in a separate draft, or some in the bis and some in this separate draft. This is largely a matter of taste. Ultimately the WG decided that a separate draft for all the call flows was preferred. It took an exceedingly long time to get this document adequately reviewed and to resolve issues with rfc4244bis that the reviews resolved. It has been hard to get attention on this because rfc4244bis has been considered "done" for a long time by those who care. Document Quality Are there existing implementations of the protocol? NA. See the writeup for 4244bis. Have a significant number of vendors indicated their plan to implement the specification? NA. See the writeup for 4244bis. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Dale Worley did very heavy lifting reviewing all of these call flows, checking all the details. He deserves five gold stars. Roland Jesske, Laura Liess, and Marianne Mohali also did careful reviews that led to fixes. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There is nothing in this document that calls for an expert review. Personnel Who is the Document Shepherd? Paul Kyzivat Who is the Responsible Area Director? Richard Barnes From iesg-secretary@ietf.org Thu Jan 2 09:28:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F81AD9AD; Thu, 2 Jan 2014 09:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718jictI_XlH; Thu, 2 Jan 2014 09:28:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D140D1AE570; Thu, 2 Jan 2014 09:28:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140102172841.20273.91204.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2014 09:28:41 -0800 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'Resource Priority Header (RPH) Registry Management Policy to IETF Review' to Proposed Standard (draft-rosen-rph-reg-policy-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 17:28:47 -0000 The IESG has approved the following document: - 'Resource Priority Header (RPH) Registry Management Policy to IETF Review' (draft-rosen-rph-reg-policy-01.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy/ Technical Summary: RFC4412 defines "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC4412 to change the management policy of these registries to "IETF Review". Working Group Summary: Discussion in the SIPCORE working group was minimal. Aside from some editorial changes, the only substantive comment was a request for further clarifications to RFC 4412. The suggested additional work was not taken on in this document. Document Quality: The document is a trivial update to RFC 4412, and its purpose is clear and unambiguous. The document is administrative in nature, and as such does not propose protocol mechanisms. Personnel: Adam Roach is the document shepherd. Richard Barnes is the responsible area director. RFC Editor Note Please make the following edits before publication: OLD: """ Experience has suggested that a document that only defines a new namespace with its priorities, and does not create new protocol semantics, should not be a standards-track document """ NEW: """ After further consideration, the IETF has concluded that documents that only define new SIP resource priority namespaces and values do not need to be on the standards track, since they do not create new protocol semantics. """ OLD: """ This document updates [RFC4412] to change the management policy of the registries to "IETF Review". """ NEW: """ This document updates RFC 4412 by changing tha IANA management policy of the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries to "IETF Review". """ OLD """ The management policy of these registries is "Standards Action" as defined in [RFC5226]. """ NEW """ The management policy of these registries defined by RFC 4412 was "Standards Action" as defined in [RFC5226]. """ From brett@broadsoft.com Thu Jan 2 10:04:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866DF1AC4A3 for ; Thu, 2 Jan 2014 10:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d0vQsBK3WMd for ; Thu, 2 Jan 2014 10:04:37 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id C6BBD1AC499 for ; Thu, 2 Jan 2014 10:04:37 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 2 Jan 2014 10:04:40 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 2 Jan 2014 10:04:40 -0800 From: Brett Tate To: Vintaur Chen , "sipcore@ietf.org" Thread-Topic: [Technical Errata Reported] RFC3325 (3744) Thread-Index: AQHPB9CFSvFr3dbSU0iLkG2rq+rhKJpxn8sA Date: Thu, 2 Jan 2014 18:04:39 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06EDE1@MBX08.citservers.local> References: <20131008184950.F23A0B1E013@rfc-editor.org> <576A8B541C219D4E9CEB1DF8C19C7B881A062F18@MBX08.citservers.local> <525569CF.4080709@alum.mit.edu> <9FA07B6E-F3B2-4E3F-B59E-58109B71BD59@amsl.com> In-Reply-To: <9FA07B6E-F3B2-4E3F-B59E-58109B71BD59@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] [Technical Errata Reported] RFC3325 (3744) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 18:04:39 -0000 Hi Vintaur, I'm replying on sipcore so that maybe consensus can be reached concerning t= he topic and errata status adjusted accordingly. Based upon the following thread, I thought that a consensus had been reache= d. http://www.ietf.org/mail-archive/web/sipcore/current/msg05730.html=20 > I disagree with Errata ID:=A03744=A0of RFC 3325, for reasons below. >=A0 > 1.=A0There is no ambiguity in current RFC definition, so the=20 > Errata is unnecessary. > > The RFC 3261 section 20 rule is involved to avoid the=20 > ambiguity between URI parameters and header parameters. The semicolon is only one aspect; it also helps with comma and question mar= k. For instance, should the following decode into 1 or 2 PAssertedID-value? A= FAIK, it is ambiguous unless the angle brackets are used. P-Asserted-Identity:sip:a.invalid,sip:password@b.invalid > This is not necessary for PAI header, as PAI header has=20 > no header parameters at all. > > 2.=A0Errata 3744 is not align with current RFC 3325, so=20 > the Errata is incorrect: >=A0 > Consider the PAI header below: > - P-Asserted-Identity: tel:+98765432109@172.17.151.36;cpc=3Dordinary123 > > Per current RFC description, the above header is a valid PAI=20 > header, with no ambiguity. > > Per Errata 3744, the above header is invalid. And Errata=20 > 3744 not descript how to handle such "invalid" header. The above header is malformed because '@' is not a phonedigit. However, I = understand the example and it is discussed within the following thread. http://www.ietf.org/mail-archive/web/sipcore/current/msg05730.html=20 > RFC 3261 section 20 clearly statement that the rule only=20 > applicable for URI in Contact/From/To header. I agree. > So, it should not be applicable for any other header unless=20 > clearly statement in RFC. I agree with the interpretation; however RFC modification is needed to avoi= d decode ambiguity. The same applies concerning the headers discussed within the following link= . http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html Thanks, Brett From mary.ietf.barnes@gmail.com Mon Jan 6 09:57:56 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322FA1AE13D; Mon, 6 Jan 2014 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT5Jp0jkElVC; Mon, 6 Jan 2014 09:57:53 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CC19E1AE128; Mon, 6 Jan 2014 09:57:52 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so15641962wes.26 for ; Mon, 06 Jan 2014 09:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AhpZaFbd0BvDCM3Wvt+6KVK4fHNiUgzIqHLrvBaCGZM=; b=TQwHBm+Lr3sIQjVMuvMDvgTmphV+QcguQzr/bFfZEDPZBbDhQOY8n2btuJ52naTsuP Wc/WhwHeVw7xq5uocVYJV5Ag63h29Jf6opzH3IYSiuRoArdPUkwHXd0DpB7h7M1tlNes EhMf5wZ/kiJ5An+uR1JBhJyfaMe0GlrQ6HRxZn+xwIt3zR4OFkNjj/meHIj31NmZu0jA nrk63eYc6A2w2jakk/nNTCp/uSOT/Fay2kM+dBcI3C+8sgE3Y4rZgce8frJwrIB2ua1W QtnhGdgHVPPMjExcKGwEyENyqcXuv0bZUWpY8sWbsbNedp3RhAjfS90Wtw8AoV1xrr+D shWA== MIME-Version: 1.0 X-Received: by 10.180.210.131 with SMTP id mu3mr9951698wic.36.1389031063850; Mon, 06 Jan 2014 09:57:43 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 6 Jan 2014 09:57:43 -0800 (PST) In-Reply-To: <52cae834.c3e7340a.687e.4e41SMTPIN_ADDED_BROKEN@mx.google.com> References: <52cae834.c3e7340a.687e.4e41SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 6 Jan 2014 11:57:43 -0600 Message-ID: From: Mary Barnes To: "rai@ietf.org" , SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary=001a11c38d7024942804ef50ffb0 Subject: [sipcore] Fwd: [SIPForum-techwg] SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:57:56 -0000 --001a11c38d7024942804ef50ffb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought this might be of interest since SIPNOC is directly relevant to many folks subscribed to these mailing lists. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Mon, Jan 6, 2014 at 11:28 AM Subject: [SIPForum-techwg] SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! To: techwg@sipforum.org SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! *Proposals are being accepted for workshops, panels, speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions addressing the deployment= of SIP in service provider environments at SIPNOC 2014, June 9 -12, 2014.* A three-day educational conference focusing on the challenges and opportunities related to the deployment of SIP-based carrier services globally, SIPNOC 2014 is a unique, network operator-centric event. Organizers invite companies, executives and industry insiders to propose presentations highlighting the use of session initiation protocol (SIP) in service provider environments. Operators are encouraged to present SIP-related success stories, deployment issues and concerns in their networks, while equipment vendors and other industry stakeholders are invited to work with operators to present real-world deployment experiences= . The SIPNOC conferences attract leading technical and operations personnel from the global carrier community and have earned high praise from attendees for their educational, non-commercial and technical content that focuses on the real-world challenges operators face when deploying SIP services in global IP networks. SIPNOC 2014 attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. SIPNOC 2014 Call for Presentations proposals can be submitted by visiting the SIP Forum SIPNOC 2014 Call for Presentations site. Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2014 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: The SIPNOC 2014 program has been expanded to include special workshops that run for 2-3 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. The following is a complete list of key dates for the SIPNOC 2014 speaking program: - Presentation Abstracts Due =E2=80=93 January 31, 2014 - Draft Presentations Due -- February 15, 2014 - Acceptance Decision and Notifications -- February 21, 2014 - Draft Program Published =E2=80=93 March 1, 2014 - Final Presentations Due -- April 1, 2014 - Final Agenda Published -- April 15, 2014 - Conference Begins -- June 9, 2014 ------------------------------ *SIPNOC 2014 General Info* The SIPNOC 2014 event website is located at www.sipnoc.org. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2014. Registration for SIPNOC 2014 is officially open! Special pricing for SIPNOC 2014 is now in effect! Take advantage of special early-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conference registration fee is $995, but for a limited time regular attendees can save $145 and pay only $850 for three days of conference proceedings. This fee includes a special welcome reception the evening before the event with food and drink; breakfast, lunch and break refreshments and snacks; and special networking receptions the first and second night of the event. *Individuals from SIP Forum Full Member companies save even more ($295 off the regular price to be exact with special early-bird pricing)! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at www.regonline.com/sipnoc2014. ------------------------------ *SIPNOC 2014 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2014, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a11c38d7024942804ef50ffb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought this might be of interest since SIPNOC is direct= ly relevant to many folks subscribed to these mailing lists.=C2=A0

=
Regards,
Mary.

-----= ----- Forwarded message ----------
From: Marc Robins <<= a href=3D"mailto:marc.robins@sipforum.org">marc.robins@sipforum.org>=
Date: Mon, Jan 6, 2014 at 11:28 AM
Subject: [SIPForum-techwg]= SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines E= xtended!
To: techwg@sipforum.org

<= br>

SIPNOC 2014 Call for Presenta= tions and Early-Bird Registration Deadlines Extended!<= /h1>

Proposals are being accepted= for workshops, panels, speaker presentations and =E2=80=9CBirds of a Feath= er=E2=80=9D sessions addressing the deployment of SIP in service provider e= nvironments at SIPNOC 2014, June 9 -12= , 2014.

A= three-day educational conference focusing on the challenges and opportunit= ies related to the deployment of SIP-based carrier services globally, SIPNO= C 2014 is a unique, network operator-centric event. Organizers invite compa= nies, executives and industry insiders to propose presentations highlightin= g the use of session initiation protocol (SIP) in service provider environm= ents. Operators are encouraged to present SIP-related success stories, depl= oyment issues and concerns in their networks, while equipment vendors and o= ther industry stakeholders are invited to work with operators to present re= al-world deployment experiences.

T= he SIPNOC conferences attract leading technical and operations personnel fr= om the global carrier community and have earned high praise from attendees = for their educational, non-commercial and technical content that focuses on= the real-world challenges operators face when deploying SIP services in gl= obal IP networks. SIPNOC 2014 attendees will include telecommunications pro= viders, major backbone operators, interconnect and wholesale solution provi= ders, ISPs, cable operators, wireless network operators as well as large en= terprises deploying major SIP initiatives.

S= IPNOC 2014 Call for Presentations proposals can be submitted by visiting th= e SIP Forum SIPNOC 2014 Call for Presentations site. Possible topics c= an include SIP peering, SIP trunking, Emergency Services, Congestion Contro= l, Scaling and Capacity Issues, SIP-based applications, Routing, Security, = SIP-Network Operations Center Best Practices, IPv6 deployment challenges, U= ser-agent Configuration, Standardization Issues and Progress, HD voice depl= oyments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Test= ing or other issues facing SIP network operations.

S= IPNOC 2014 offers several different types of speaking opportunities includi= ng:

  • General Session Talks: A General Session presen= tation should be on a topic of interest to the general SIPNOC audience, and= may be up to 30 minutes long (including time for Q&A). <= /span>
  • General Session Pa= nels: Panels are sessions with a moderator and a team of panelists. The pan= el moderator should submit an abstract on the panel topic, a list of paneli= sts, and how the panel will be organized. Panel selection is based on the i= mportance, originality, focus and timeliness of the topic, expertise of pro= posed panelists, as well as the potential for informative and controversial= discussion.
  • Special Workshops:= The SIPNOC 2014 program has been expanded to include special workshops tha= t run for 2-3 hours, providing time to focus in-depth on a variety of issue= s important to the SIPNOC community. Topics can include a review of SIP RFC= s and standards development, the regulatory environment, etc.=
  • Research Topics: R= esearchers are invited to present short summaries of their work for operato= r feedback. Topics may include call routing, network performance, statistic= al measurement and analysis and protocol development and implementation. St= udies presented may be works in progress. Researchers from academia, govern= ment, and industry are encouraged to present.
  • BOFs: BOFs (Birds = of a Feather sessions) are informal sessions on topics which are of interes= t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o= ut areas or in an unscheduled room. Requests for scheduled BOFs can be made= at any time, including on site at the conference.

The following is a complete list of key dates for the SIPNOC 2014 speak= ing program:

  • Presentation Abstracts Due =E2=80=93 Janua= ry 31, 2014
  • Draft Presentations Due -- February 15, 2014
  • Acceptance Decisio= n and Notifications -- February 21, 2014
  • Draft Program Published =E2= =80=93 March 1, 2014
  • Final Presentation= s Due -- April 1, 2014
  • Final Agenda Published -- April 15, 2014
  • Conference Begins = -- June 9, 2014

=C2=A0

SIPNOC 2014 General Info

The= SIPNOC 2014 event website is located at www.sipnoc.org.

T= o view the official call for presentations, which includes instructions on = submitting material and specific SIPNOC policies, please visit www.sipforu= m.org/content/view/374/275/. To submit, visit https://www.e= asychair.org/conferences/?conf=3Dsipnoc2014.

R= egistration for SIPNOC 2014 is officially open!

= Spec= ial pricing for SIPNOC 2014 is now in effect! Take advantage of special ear= ly-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conferen= ce registration fee is $995, but for a limited time regular attendees can s= ave $145 and pay only $850 for three days of conference proceedings. This f= ee includes a special welcome reception the evening before the event with f= ood and drink; breakfast, lunch and break refreshments and snacks; and spec= ial networking receptions the first and second night of the event.

Individuals from SIP Forum Full Member companies save even m= ore ($295 off the regular price to be exact with special early-bird pricing= )! Please contact Marc Robins, SIP Forum President and Managing Director, a= t marc.robins= @sipforum.org to obtain the exclusive Full Member discount code.=

R= egister today at www.regonline.com/sipnoc2014.=C2=A0

SIPNOC 2014 Sponsorship Information

F= or information about corporate sponsorship opportunities at SIPNOC 2014, pl= ease contact Marc Robins, SIP Forum President and Managing Director, at 203-829-= 6307 or m= arc.robins@sipforum.org.

=

*************************

Marc Robins

President and Managing Director<= u>

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307<= /p>

SkypeMe! marcrobins

=C2=A0

**************= ***********

=C2=A0

=C2=A0


________________________________________= _______
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--001a11c38d7024942804ef50ffb0-- From rifaat.ietf@gmail.com Fri Jan 10 16:48:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06411AC404 for ; Fri, 10 Jan 2014 16:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40sRtla3EOTL for ; Fri, 10 Jan 2014 16:48:21 -0800 (PST) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7F99E1AC441 for ; Fri, 10 Jan 2014 16:48:21 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b15so2190126eek.24 for ; Fri, 10 Jan 2014 16:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=re56AbYWBXbXDrFyf1nusw6vdxF/5NRFOTfcM/GuOZg=; b=ENW/+Mnu22BTLkr3m7KcDOZ4Z3u/D5aNkP2GYp4Vb6nn2sKr9rDPYcd2cHgNiGXzDQ I5gbr0sXYf0jcYADUQbID/jQFUgPCpcXMwIoxwpriyVxX79mmPyB9Utvn7cs0mzSVgwl JhNhsb9RFja5sKIwefZkPaYyK418I4eHWla4/txTvK+MIEtGGEs2aki4iM/zZMfr3kSm wxC3rSex2X6iXJJ+csLvmsWOmUlGHX8WPnPNATfuLI59WIlNIUlL5ycMSeQrIqsGGfMh xH0zn8c7r507uDvir+PSquSCkUh6BDjH7gxxL2ufpcr1wR5pks//uh0ZtFK6UJl9Mnpm OTgA== MIME-Version: 1.0 X-Received: by 10.15.111.6 with SMTP id ci6mr7870985eeb.59.1389401289709; Fri, 10 Jan 2014 16:48:09 -0800 (PST) Received: by 10.14.53.78 with HTTP; Fri, 10 Jan 2014 16:48:09 -0800 (PST) In-Reply-To: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2014 19:48:09 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=089e0162838452ddc304efa7320d Subject: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 00:48:23 -0000 --089e0162838452ddc304efa7320d Content-Type: text/plain; charset=ISO-8859-1 Hi, This draft, https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, updates the Digest Authentication Scheme used by SIP based on the ongoing update to the HTTP Digest Authentication Scheme described here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. The document has one open issue related to the backward compatibility with RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP document is still under discussion. I would appreciate any feedback on this initial version of this document. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Fri, Jan 10, 2014 at 7:45 PM Subject: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt To: Rifaat Shekh-Yusef A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-sipcore-digest-scheme Revision: 00 Title: The Session Initiation Protocol (SIP) Digest Authentication Scheme Document date: 2014-01-10 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 Abstract: This document updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e0162838452ddc304efa7320d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi= ,

=A0

This draft,=A0= https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, up= dates the Digest Authentication Scheme used by SIP based on the ongoing update to= the HTTP Digest Authentication Scheme described here: https://datatracker.ietf.or= g/doc/draft-ietf-httpauth-digest/.

=A0

The document has one open issue related to the backward compatibility with RFC2543/RFC20= 69. The backward compatibility with RFC2069 in the HTTP document is still under discussion.

I would appreciate any feedback on this initial version of this document.

=A0

Regards,

=A0Rifaat



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification for= draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Digest Auth= entication Scheme
Document date: =A02014-01-10
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A07
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-y= usef-sipcore-digest-scheme-00


Abstract:
=A0 =A0This document updates the Digest Access Authentication scheme used b= y
=A0 =A0the Session Initiation Protocol (SIP) to add support for SHA2 digest=
=A0 =A0algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e0162838452ddc304efa7320d-- From oej@edvina.net Sat Jan 11 02:51:24 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1BD1ADBC9 for ; Sat, 11 Jan 2014 02:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0-ajeWD4R-m for ; Sat, 11 Jan 2014 02:51:22 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 931BD1ACCE4 for ; Sat, 11 Jan 2014 02:51:20 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 32FAA93C2A1; Sat, 11 Jan 2014 10:51:09 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_4FD1CB86-BC3A-466C-B03E-B2E17B12B877" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 11 Jan 2014 11:51:10 +0100 Message-Id: <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1827) Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 10:51:25 -0000 --Apple-Mail=_4FD1CB86-BC3A-466C-B03E-B2E17B12B877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef = wrote: > Hi, > =20 > This draft, = https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, = updates the Digest Authentication Scheme used by SIP based on the = ongoing update to the HTTP Digest Authentication Scheme described here: = https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. > =20 > The document has one open issue related to the backward compatibility = with RFC2543/RFC2069. The backward compatibility with RFC2069 in the = HTTP document is still under discussion. > I would appreciate any feedback on this initial version of this = document. > =20 Great to see this finally happen! A few questions: 1. If you modify the BNF and other things - doesn't this update RFC = 3261? 2. You state as an open issue whether we need to keep backwards = compatibility with 2543/2069. What do you think, what would be the effect if we = don't? 3. I would like to see a section that more clearly defines the changes = compared with 3261/2543 to make it easier for developers to understand what = they need to change and what they can keep. Cheers, /O > Regards, > Rifaat >=20 >=20 > ---------- Forwarded message ---------- > From: > Date: Fri, Jan 10, 2014 at 7:45 PM > Subject: New Version Notification for = draft-yusef-sipcore-digest-scheme-00.txt > To: Rifaat Shekh-Yusef >=20 >=20 >=20 > A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to = the > IETF repository. >=20 > Name: draft-yusef-sipcore-digest-scheme > Revision: 00 > Title: The Session Initiation Protocol (SIP) Digest = Authentication Scheme > Document date: 2014-01-10 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > Htmlized: = http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 >=20 >=20 > Abstract: > This document updates the Digest Access Authentication scheme used = by > the Session Initiation Protocol (SIP) to add support for SHA2 = digest > algorithms to replace the MD5 algorithm. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_4FD1CB86-BC3A-466C-B03E-B2E17B12B877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 11 Jan 2014, at 01:48, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> = wrote:

Hi,

 

This draft, https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/= , updates the Digest Authentication Scheme used by SIP based on the ongoing update = to the HTTP Digest Authentication Scheme described here: http= s://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/.

 

The = document has one open issue related to the backward compatibility with = RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP document is still = under discussion.

I = would appreciate any feedback on this initial version of this document.

 
Great to see = this finally happen!

A few = questions:

1. If you modify the BNF and other = things - doesn't this update RFC 3261?
2. You state as an open = issue whether we need to keep backwards compatibility
  =  with 2543/2069. What do you think, what would be the effect if we = don't?
3. I would like to see a section that more clearly = defines the changes compared
    with 3261/2543 to = make it easier for developers to understand what they
  =   need to change and what they can = keep.

Cheers,
/O


Regards,

 Rifaat



---------- Forwarded message ----------
From: = <internet-drafts@ietf.org><= /span>
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification = for draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com>


A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to = the
IETF repository.

Name:           = draft-yusef-sipcore-digest-scheme
Revision:       00
Title:          The Session Initiation Protocol = (SIP) Digest Authentication Scheme
Document date:  2014-01-10
Group:          Individual Submission
Pages:          7
URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-= digest-scheme-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yusef-sipcore-dig= est-scheme/
Htmlized:       http://tools.ietf.org/html/draft-yusef-sipcore-digest-sc= heme-00


Abstract:
   This document updates the Digest Access Authentication = scheme used by
   the Session Initiation Protocol (SIP) to add support for = SHA2 digest
   algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
sipcore mailing = list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

= --Apple-Mail=_4FD1CB86-BC3A-466C-B03E-B2E17B12B877-- From rifaat.ietf@gmail.com Sat Jan 11 18:27:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0521AD8C4 for ; Sat, 11 Jan 2014 18:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8HNX6zT1ZKu for ; Sat, 11 Jan 2014 18:27:57 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B1DC11AD672 for ; Sat, 11 Jan 2014 18:27:56 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id d10so2665543eaj.37 for ; Sat, 11 Jan 2014 18:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4F3eMGl963o0J3z2WDSYI6CXtb8Vsc+o+A1zdnFxKGQ=; b=kPWJMq8CQBK8jQqBHkak4qiyVuLPorrgzM6pJxAbC/XOcjIMlNYmKbqOkeP4tm3R6B g+vw8+ZX6rUObPGuDgSePird2we+big2p16N+u4O8nXXUooewH7yYT1Beh7kQM6k2pWg 7VZkkKA4D31Llhlt4wUsnt2NiVapfGktVr0IgL8AGDteyIwi7UlObRTwTPO6+l9bSFK/ E1UNdgeRzASgBOU5R1GhErchj/m6Bixy/MetQPEEcCmhmVEqv80901oXwf9eJdvrsX3Z W1ausQVagSqO57fDt6gs1EcTp6kg+I71tq2MutNu7TjqVEzPsTDQGH6Iqmmw/izkk+J4 zvow== MIME-Version: 1.0 X-Received: by 10.14.122.5 with SMTP id s5mr18740841eeh.28.1389493665374; Sat, 11 Jan 2014 18:27:45 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 11 Jan 2014 18:27:45 -0800 (PST) In-Reply-To: <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> Date: Sat, 11 Jan 2014 21:27:45 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a11c1b83857a5a604efbcb4fe Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 02:27:59 -0000 --001a11c1b83857a5a604efbcb4fe Content-Type: text/plain; charset=ISO-8859-1 Thanks Olle, See my replies inline... Regards, Rifaat On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson wrote: > > On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef > wrote: > > Hi, > > > This draft, > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, > updates the Digest Authentication Scheme used by SIP based on the ongoing > update to the HTTP Digest Authentication Scheme described here: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. > > > > The document has one open issue related to the backward compatibility with > RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP > document is still under discussion. > > I would appreciate any feedback on this initial version of this document. > > > Great to see this finally happen! > > A few questions: > > 1. If you modify the BNF and other things - doesn't this update RFC 3261? > Yes, I will add that to the next version of the draft. > 2. You state as an open issue whether we need to keep backwards > compatibility > with 2543/2069. What do you think, what would be the effect if we don't? > That depends on what we have out there. Are there are many deployed systems that comply to RFC2543 but not RFC3261? Do most proxies add the "qop" parameter today? > 3. I would like to see a section that more clearly defines the changes > compared > with 3261/2543 to make it easier for developers to understand what they > need to change and what they can keep. > > Ok. > Cheers, > /O > > > Regards, > > Rifaat > > > > ---------- Forwarded message ---------- > From: > Date: Fri, Jan 10, 2014 at 7:45 PM > Subject: New Version Notification for > draft-yusef-sipcore-digest-scheme-00.txt > To: Rifaat Shekh-Yusef > > > > A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-digest-scheme > Revision: 00 > Title: The Session Initiation Protocol (SIP) Digest > Authentication Scheme > Document date: 2014-01-10 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > Htmlized: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 > > > Abstract: > This document updates the Digest Access Authentication scheme used by > the Session Initiation Protocol (SIP) to add support for SHA2 digest > algorithms to replace the MD5 algorithm. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --001a11c1b83857a5a604efbcb4fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Olle,

See my replies inline...

Regards,
=A0Rifaat



On Sat, Jan 11,= 2014 at 5:51 AM, Olle E. Johansson <oej@edvina.net> wrote:

On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= /div>

Hi,

=A0

This draft,=A0https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, u= pdates the Digest Authentication Scheme used by SIP based on the ongoing update to= the HTTP Digest Authentication Scheme described here: https://d= atatracker.ietf.org/doc/draft-ietf-httpauth-digest/.

=A0

The docu= ment has one open issue related to the backward compatibility with RFC2543/RFC20= 69. The backward compatibility with RFC2069 in the HTTP document is still under discussion.

I wo= uld appreciate any feedback on this initial version of this document.

=A0
Great to see thi= s finally happen!

A few questions:

1. If you modify the BNF and other things - doesn't this upd= ate RFC 3261?

Yes, I will add t= hat to the next version of the draft.

=A0
2. You state as an open issue whet= her we need to keep backwards compatibility
=A0 =A0with 2543/2069= . What do you think, what would be the effect if we don't?
<= /blockquote>

That depends on what we have out there.
Are t= here are many deployed systems that comply to RFC2543 but not RFC3261?
Do most proxies add the "qop" parameter today?


=A0
3. I would like to see a section that more clearly defines the changes= compared
=A0 =A0 with 3261/2543 to make it easier for developers= to understand what they
=A0 =A0 need to change and what they can= keep.


Ok.


=A0
Cheers,
/O


R= egards,

=A0Rifaat



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification for= draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.c= om>



A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Digest Auth= entication Scheme
Document date: =A02014-01-10
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A07
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-y= usef-sipcore-digest-scheme-00


Abstract:
=A0 =A0This document updates the Digest Access Authentication scheme used b= y
=A0 =A0the Session Initiation Protocol (SIP) to add support for SHA2 digest=
=A0 =A0algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


--001a11c1b83857a5a604efbcb4fe-- From oej@edvina.net Sun Jan 12 01:36:40 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911341ADF86 for ; Sun, 12 Jan 2014 01:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LLy7oUNASp2 for ; Sun, 12 Jan 2014 01:36:37 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 510AE1AC8F5 for ; Sun, 12 Jan 2014 01:36:34 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CF85593C2A3; Sun, 12 Jan 2014 09:36:22 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_732C4B4B-294F-489E-868F-EF74BC561E73" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 12 Jan 2014 10:36:20 +0100 Message-Id: References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1827) Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 09:36:40 -0000 --Apple-Mail=_732C4B4B-294F-489E-868F-EF74BC561E73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef = wrote: > Thanks Olle, >=20 > See my replies inline... >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson = wrote: >=20 > On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef = wrote: >=20 >> Hi, >> =20 >> This draft, = https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, = updates the Digest Authentication Scheme used by SIP based on the = ongoing update to the HTTP Digest Authentication Scheme described here: = https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. >> =20 >> The document has one open issue related to the backward compatibility = with RFC2543/RFC2069. The backward compatibility with RFC2069 in the = HTTP document is still under discussion. >> I would appreciate any feedback on this initial version of this = document. >> =20 > Great to see this finally happen! >=20 > A few questions: >=20 > 1. If you modify the BNF and other things - doesn't this update RFC = 3261? >=20 > Yes, I will add that to the next version of the draft. Before Cullen says it: Do we have to update RFC3261 meaning that everyone is forced to update = to stay=20 compliant with SIP? Or can we do this as an optional addon? Moving forward and leaving MD5 behind is desirable, but maybe not = declaring devices incompatible with SIP. What is the opinion of the SIPcore group? >=20 > =20 > 2. You state as an open issue whether we need to keep backwards = compatibility > with 2543/2069. What do you think, what would be the effect if we = don't? >=20 > That depends on what we have out there. > Are there are many deployed systems that comply to RFC2543 but not = RFC3261? > Do most proxies add the "qop" parameter today? Good question. Are proxys really allowed to mess with the authentication = headers? If we make this an optional specification, possibly with a supported = header, like Supported: strongauth then we can get rid of the old stuff. And maybe such a header would help = migration. The server in that case doesn't have to downgrade to md5 and can make a = decision on whether it requires this to proceed. Opinions? /O >=20 >=20 > =20 > 3. I would like to see a section that more clearly defines the changes = compared > with 3261/2543 to make it easier for developers to understand what = they > need to change and what they can keep. >=20 >=20 > Ok. >=20 >=20 > =20 > Cheers, > /O >=20 >=20 >> Regards, >> Rifaat >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Jan 10, 2014 at 7:45 PM >> Subject: New Version Notification for = draft-yusef-sipcore-digest-scheme-00.txt >> To: Rifaat Shekh-Yusef >>=20 >>=20 >>=20 >> A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt >> has been successfully submitted by Rifaat Shekh-Yusef and posted to = the >> IETF repository. >>=20 >> Name: draft-yusef-sipcore-digest-scheme >> Revision: 00 >> Title: The Session Initiation Protocol (SIP) Digest = Authentication Scheme >> Document date: 2014-01-10 >> Group: Individual Submission >> Pages: 7 >> URL: = http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.t= xt >> Status: = https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >> Htmlized: = http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 >>=20 >>=20 >> Abstract: >> This document updates the Digest Access Authentication scheme used = by >> the Session Initiation Protocol (SIP) to add support for SHA2 = digest >> algorithms to replace the MD5 algorithm. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_732C4B4B-294F-489E-868F-EF74BC561E73 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Olle,

See my replies inline...

Regards,
 Rifaat



On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson <oej@edvina.net> wrote:

On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi,

 

This draft, https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, updates the Digest Authentication Scheme used by SIP based on the ongoing update to the HTTP Digest Authentication Scheme described here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/.

 

The document has one open issue related to the backward compatibility with RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP document is still under discussion.

I would appreciate any feedback on this initial version of this document.

 
Great to see this finally happen!

A few questions:

1. If you modify the BNF and other things - doesn't this update RFC 3261?

Yes, I will add that to the next version of the draft.
Before Cullen says it:

Do we have to update RFC3261 meaning that everyone is forced to update to stay 
compliant with SIP? Or can we do this as an optional addon?

Moving forward and leaving MD5 behind is desirable, but maybe not declaring devices
incompatible with SIP. What is the opinion of the SIPcore group?


 
2. You state as an open issue whether we need to keep backwards compatibility
   with 2543/2069. What do you think, what would be the effect if we don't?

That depends on what we have out there.
Are there are many deployed systems that comply to RFC2543 but not RFC3261?
Do most proxies add the "qop" parameter today?
Good question. Are proxys really allowed to mess with the authentication headers?

If we make this an optional specification, possibly with a supported header, like

Supported: strongauth

then we can get rid of the old stuff. And maybe such a header would help migration.
The server in that case doesn't have to downgrade to md5 and can make a decision
on whether it requires this to proceed.

Opinions?

/O


 
3. I would like to see a section that more clearly defines the changes compared
    with 3261/2543 to make it easier for developers to understand what they
    need to change and what they can keep.


Ok.


 
Cheers,
/O


Regards,

 Rifaat



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>



A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-sipcore-digest-scheme
Revision:       00
Title:          The Session Initiation Protocol (SIP) Digest Authentication Scheme
Document date:  2014-01-10
Group:          Individual Submission
Pages:          7
URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/
Htmlized:       http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00


Abstract:
   This document updates the Digest Access Authentication scheme used by
   the Session Initiation Protocol (SIP) to add support for SHA2 digest
   algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--Apple-Mail=_732C4B4B-294F-489E-868F-EF74BC561E73-- From rifaat.ietf@gmail.com Sun Jan 12 05:12:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC06E1AE07E for ; Sun, 12 Jan 2014 05:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds2c5KvXYjps for ; Sun, 12 Jan 2014 05:12:09 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 005FC1ADF56 for ; Sun, 12 Jan 2014 05:12:08 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e51so2249037eek.34 for ; Sun, 12 Jan 2014 05:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e3hIXFitjBLNLjp3LK4hZCCixRVhOZ7rw7aWnSWt6zM=; b=HyMQX8EKiPyCh4WFu9AK9FNs16fYQ8c6UztiF/sTKsyxOZw5Xk7cAdOeCfovVnFRUp zXOr7ue6kyMa3Eo2gq4lNeCTOoxvAwxRNdbgHPNbkv1wtEHwNxTtwEGenkxoOXUqjGQ8 pZSalZfEc0eyQOn0ddCIYObSiCDXPdtXU3ST0qS7btozBjQ1qtgA48ZC9cbLnKphUvqe e6CVX3Ly3PZxfHayzQH5t1RSP6GeiJEBsMX0POtiwkcPFx6tJ7/4eq5HE4DZuXIQe+YL WpDjUhy4wTjTiN6UBrRElgSmH6xC5/BI946HY/I823QF+CDCr3+xdA1czlcXljqSicM/ KNgw== MIME-Version: 1.0 X-Received: by 10.14.220.136 with SMTP id o8mr9179012eep.97.1389532282732; Sun, 12 Jan 2014 05:11:22 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 12 Jan 2014 05:11:22 -0800 (PST) In-Reply-To: References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> Date: Sun, 12 Jan 2014 08:11:22 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7b621f1e1dc3d804efc5b2ba Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 13:12:13 -0000 --047d7b621f1e1dc3d804efc5b2ba Content-Type: text/plain; charset=ISO-8859-1 Maybe I was not clear enough. The draft is *not *deprecating MD5, but leaves it there for backward compatibility. This is explained in the HTTP draft. The question is around the use of "qop" today which is optional in RFC2617 and still under discussion in the HTTP draft to understand the impact there. Regards, Rifaat On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson wrote: > > On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef > wrote: > > Thanks Olle, > > See my replies inline... > > Regards, > Rifaat > > > > On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson wrote: > >> >> On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef >> wrote: >> >> Hi, >> >> >> This draft, >> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, >> updates the Digest Authentication Scheme used by SIP based on the ongoing >> update to the HTTP Digest Authentication Scheme described here: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. >> >> >> >> The document has one open issue related to the backward compatibility >> with RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP >> document is still under discussion. >> >> I would appreciate any feedback on this initial version of this document. >> >> >> Great to see this finally happen! >> >> A few questions: >> >> 1. If you modify the BNF and other things - doesn't this update RFC 3261? >> > > Yes, I will add that to the next version of the draft. > > Before Cullen says it: > > Do we have to update RFC3261 meaning that everyone is forced to update to > stay > compliant with SIP? Or can we do this as an optional addon? > > Moving forward and leaving MD5 behind is desirable, but maybe not > declaring devices > incompatible with SIP. What is the opinion of the SIPcore group? > > > > >> 2. You state as an open issue whether we need to keep backwards >> compatibility >> with 2543/2069. What do you think, what would be the effect if we >> don't? >> > > That depends on what we have out there. > Are there are many deployed systems that comply to RFC2543 but not RFC3261? > Do most proxies add the "qop" parameter today? > > Good question. Are proxys really allowed to mess with the authentication > headers? > > If we make this an optional specification, possibly with a supported > header, like > > Supported: strongauth > > then we can get rid of the old stuff. And maybe such a header would help > migration. > The server in that case doesn't have to downgrade to md5 and can make a > decision > on whether it requires this to proceed. > > Opinions? > > /O > > > > > >> 3. I would like to see a section that more clearly defines the changes >> compared >> with 3261/2543 to make it easier for developers to understand what >> they >> need to change and what they can keep. >> >> > Ok. > > > > >> Cheers, >> /O >> >> >> Regards, >> >> Rifaat >> >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Jan 10, 2014 at 7:45 PM >> Subject: New Version Notification for >> draft-yusef-sipcore-digest-scheme-00.txt >> To: Rifaat Shekh-Yusef >> >> >> >> A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt >> has been successfully submitted by Rifaat Shekh-Yusef and posted to the >> IETF repository. >> >> Name: draft-yusef-sipcore-digest-scheme >> Revision: 00 >> Title: The Session Initiation Protocol (SIP) Digest >> Authentication Scheme >> Document date: 2014-01-10 >> Group: Individual Submission >> Pages: 7 >> URL: >> http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >> Htmlized: >> http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 >> >> >> Abstract: >> This document updates the Digest Access Authentication scheme used by >> the Session Initiation Protocol (SIP) to add support for SHA2 digest >> algorithms to replace the MD5 algorithm. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --047d7b621f1e1dc3d804efc5b2ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe I was not clear enough.
The draft is not = deprecating MD5, but leaves it there for backward compatibility. This is ex= plained in the HTTP draft.

The question is around = the use of "qop" today which is optional in RFC2617 and still und= er discussion in the HTTP draft to understand the impact there.

Regards,
=A0Rifaat


On Sun, Jan 12, 2014 at 4:36= AM, Olle E. Johansson <oej@edvina.net> wrote:

On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef <rifaat.ietf@gmail.= com> wrote:

Thanks Olle,

<= div>See my replies inline...

Regards,
= =A0Rifaat



On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson <oej@edvina.net> wrote:

On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:<= /div>

Hi,

=A0

This draft,=A0https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, u= pdates the Digest Authentication Scheme used by SIP based on the ongoing update to= the HTTP Digest Authentication Scheme described here: https://d= atatracker.ietf.org/doc/draft-ietf-httpauth-digest/.

=A0

The docu= ment has one open issue related to the backward compatibility with RFC2543/RFC20= 69. The backward compatibility with RFC2069 in the HTTP document is still under discussion.

I wo= uld appreciate any feedback on this initial version of this document.

=A0
Great to see thi= s finally happen!

A few questions:

1. If you modify the BNF and other things - doesn't this upd= ate RFC 3261?

Yes, I will add t= hat to the next version of the draft.
Before Cullen says it:

Do we have to update = RFC3261 meaning that everyone is forced to update to stay=A0
comp= liant with SIP? Or can we do this as an optional addon?

Moving forward and leaving MD5 behind is desirable, but maybe not decl= aring devices
incompatible with SIP. What is the opinion of the S= IPcore group?


=A0
2. You state as an open issue whet= her we need to keep backwards compatibility
=A0 =A0with 2543/2069= . What do you think, what would be the effect if we don't?
<= /blockquote>

That depends on what we have out there.
Are t= here are many deployed systems that comply to RFC2543 but not RFC3261?
Do most proxies add the "qop" parameter today?
Good question. Are proxys really allowed to = mess with the authentication headers?

If we make t= his an optional specification, possibly with a supported header, like

Supported: strongauth

then we = can get rid of the old stuff. And maybe such a header would help migration.=
The server in that case doesn't have to downgrade to md5 and= can make a decision
on whether it requires this to proceed.

Opini= ons?

/O



=A0
3. I would like to see a section that more clearly defines the changes= compared
=A0 =A0 with 3261/2543 to make it easier for developers= to understand what they
=A0 =A0 need to change and what they can= keep.


Ok.


=A0
Cheers,
/O


Regards,

=A0Rifaat



---------- Forwarded message ----------From: <internet-drafts@ietf.org= >
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification for= draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.c= om>



A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Digest Auth= entication Scheme
Document date: =A02014-01-10
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A07
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-y= usef-sipcore-digest-scheme-00


Abstract:
=A0 =A0This document updates the Digest Access Authentication scheme used b= y
=A0 =A0the Session Initiation Protocol (SIP) to add support for SHA2 digest=
=A0 =A0algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


--047d7b621f1e1dc3d804efc5b2ba-- From pkyzivat@alum.mit.edu Mon Jan 13 09:55:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CE81ADF89 for ; Mon, 13 Jan 2014 09:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb8NHOrGNwLE for ; Mon, 13 Jan 2014 09:55:53 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EE1ADF84 for ; Mon, 13 Jan 2014 09:55:53 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta07.westchester.pa.mail.comcast.net with comcast id DQr11n0030SCNGk57Vvi9Y; Mon, 13 Jan 2014 17:55:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id DVvh1n00E3ZTu2S3VVvhhk; Mon, 13 Jan 2014 17:55:42 +0000 Message-ID: <52D4289D.8070903@alum.mit.edu> Date: Mon, 13 Jan 2014 12:55:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , Brett Tate References: <20131008184950.F23A0B1E013@rfc-editor.org> <576A8B541C219D4E9CEB1DF8C19C7B881A062F18@MBX08.citservers.local> <525569CF.4080709@alum.mit.edu> <9FA07B6E-F3B2-4E3F-B59E-58109B71BD59@amsl.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06EE48@MBX08.citservers.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389635742; bh=FZH4G3cLsy2EyqYHSBl9Wx9UKEl7WU3i9S2hofbP4W0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hBhOwLwjLXnf7HQJwrhuMggZUc6hT/nkzjKHWpESu9KKs8uF6oFFjyFhdNeUjVLlW 1Q8clpTvPtcCcAMQ6htiv87jcodjsQplNwDWU0sehj8uq0C5jfdZQ+o/6Vcq+75fbm vYL5Mc8uSJg31GjASPNFItpCs2CF7eLwKdtUZduTNFWVYWj2sdz27sXPushueCWlHc DxhPk6ziJLUrCT0L80fW54m1bTCEGVrNjofaYaBSvgcOX0byitXvTuvNk13tX2LXKM B+kDr8/7JI89xw4/sdbVjh6mlJ+oYhaFeT/vki9Ze8KrEa3L0aztCUZKmlkKneVU4W GVU+rjHZ75S0g== X-Mailman-Approved-At: Mon, 13 Jan 2014 09:57:02 -0800 Cc: Richard Barnes , "Keith \(Keith\) DRAGE" , SIPCORE , Alice Russo , Vintaur Chen , Dean Willis , "mwatson@nortelnetworks.com" Subject: Re: [sipcore] [Technical Errata Reported] RFC3325 (3744) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:55:55 -0000 The chairs have reviewed the discussions regarding this erratum. There is no ambiguity wrt ";" or "?", but there is wrt ",". So *some* sort of erratum is in order. The question is what the erratum ought to say. It would be "sufficient" to say: A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. If the URI contains a comma the URI MUST be enclosed in angle brackets (< and >). The erratum currently takes a stronger position: A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). The difference is who is at fault if there is a usage that has ";" or "?" without enclosing <>. The chairs agree with the stronger statement, because it is consistent with the behavior for other similar headers. Without the stronger statement, implementers that parse these need a special case for this header. I propose that we add an additional note to the erratum: 'While the P-Asserted-Identity and P-Preferred-Identity header fields have an ambiguity only for "," (not for ";" and "?"), we propose that usage of ";" and "?" also must be inclosed in angle brackets to preserve consistency with the RFC 3261 section 20 bracket rule.' Anyone who objects to this should speak up now, or we will proceed this way. Thanks, Paul, as sipcore co-chair On 1/6/14 12:50 PM, Cullen Jennings (fluffy) wrote: > > Yep, at this point I think we should leave it up the sip core chars to make a consensus call on this and then the ADs can decide what to do and let the RFC Ed know. > > > On Jan 2, 2014, at 12:22 PM, Brett Tate wrote: > >> Hi, >> >> I sent a reply to sipcore so that maybe consensus can be reached concerning the topic and errata status adjusted accordingly. >> >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05912.html >> >> Thanks, >> Brett >> >> From: Alice Russo [mailto:arusso@amsl.com] >> Sent: Thursday, January 02, 2014 10:36 AM >> To: Cullen Jennings >> Cc: Vintaur Chen; Paul Kyzivat; Brett Tate; Dean Willis; Adam Roach; Jon Peterson; mwatson@nortelnetworks.com; Keith (Keith) DRAGE; Richard Barnes; Gonzalo Camarillo; RFC Editor >> Subject: Re: [Technical Errata Reported] RFC3325 (3744) >> >> Cullen, >> >> Please see the mail below from Vintaur Chen (who is CC'ed) re: http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744 >> >> Also, I've directed Vintaur to the "Bug in RFC 3325" thread on the sipcore list (approx. starting with http://www.ietf.org/mail-archive/web/sipcore/current/msg05714.html). >> >> Thank you. >> RFC Editor/ar >> >> On Jan 2, 2014, at 9:04 AM, Vintaur Chen wrote: >> >> >> Hi, RFC Editor >> >> I disagree with Errata ID: 3744 of RFC 3325, for reasons below. >> >> 1. There is no ambiguity in current RFC definition, so the Errata is unnecessary. >> The RFC 3261 section 20 rule is involved to avoid the ambiguity between URI parameters and header parameters. >> This is not necessary for PAI header, as PAI header has no header parameters at all. >> >> We can make a quick comparing between PAI header and To header here: >> - PAI header has no pai-param here: >> PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) >> PAssertedID-value = name-addr / addr-spec >> - Compare this to for example the To-header: >> To = ( "To" / "t" ) HCOLON ( name-addr/ addr-spec ) *( SEMI to-param ) >> >> >> 2. Errata 3744 is not align with current RFC 3325, so the Errata is incorrect: >> >> Consider the PAI header below: >> - P-Asserted-Identity: tel:+98765432109@172.17.151.36;cpc=ordinary123 >> >> Per current RFC description, the above header is a valid PAI header, with no ambiguity. >> Per Errata 3744, the above header is invalid. And Errata 3744 not descript how to handle such “invalid” header. >> >> >> RFC 3261 section 20 clearly statement that the rule only applicable for URI in Contact/From/To header. >> So, it should not be applicable for any other header unless clearly statement in RFC. >> The Contact, From, and To header fields contain a URI. If the URI >> contains a comma, question mark or semicolon, the URI MUST be >> enclosed in angle brackets (< and >). Any URI parameters are >> contained within these brackets. If the URI is not enclosed in angle >> brackets, any semicolon-delimited parameters are header-parameters, >> not URI parameters. >> >> >> Regards >> Vintaur Chen >> >> >> On Oct 9, 2013, at 11:48 AM, Cullen Jennings (fluffy) wrote: >> >> >> >> I started a thead on sip core >> >> [...] >> >> On Oct 8, 2013, at 12:49 PM, RFC Errata System wrote: >> >> >> The following errata report has been submitted for RFC3325, >> "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744 >> >> -------------------------------------- >> Type: Technical >> Reported by: Brett Tate >> >> Section: 9.1 >> >> Original Text >> ------------- >> A P-Asserted-Identity header field value MUST consist of exactly one >> >> name-addr or addr-spec. >> >> Corrected Text >> -------------- >> A P-Asserted-Identity header field value MUST consist of exactly one >> >> name-addr or addr-spec. If the URI contains a comma, question mark >> >> or semicolon, the URI MUST be enclosed in angle brackets (< and >). >> >> Notes >> ----- >> P-Asserted-Identity ABNF defines PAssertedID-value to be name-addr / addr-spec. However, no text is added to indicate if the RFC 3261 section 20 bracket rule fully applies, partially applies, or does not apply. Some of the confusion is caused by the ABNF not allowing the header to contain parameters. >> >> >> >> The same bracket rule should be added to section 9.2 for P-Preferred-Identity. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3325 (draft-ietf-sip-asserted-identity-01) >> -------------------------------------- >> Title : Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks >> Publication Date : November 2002 >> Author(s) : C. Jennings, J. Peterson, M. Watson >> Category : INFORMATIONAL >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> >> > > From pkyzivat@alum.mit.edu Tue Jan 14 09:52:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476C1AE0D6 for ; Tue, 14 Jan 2014 09:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcKQPmOyFppf for ; Tue, 14 Jan 2014 09:52:01 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id E70A91ADF28 for ; Tue, 14 Jan 2014 09:52:00 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id DsKZ1n0050EZKEL5Ftrp23; Tue, 14 Jan 2014 17:51:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id Dtrp1n00P3ZTu2S3MtrpsF; Tue, 14 Jan 2014 17:51:49 +0000 Message-ID: <52D57935.1070204@alum.mit.edu> Date: Tue, 14 Jan 2014 12:51:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389721909; bh=+ecVNyZw2rLyctpyNiJ/VJWMqgzvRx8HTkeL018gYII=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WwhyOc4hUO+7uKRUR2T35uXtn4ysdjHgr+26c3uL2b67lKCYmkjwpXwjZckEFwpkz bM8wT0L1E/4er0e19H+UFylbyGdRNVsRiCis8UPigKeE1mqTQZfHdIDWV3ijRqtkc2 eOgeyKUZoXkScegmvKH/dc3SQmRILYeP8MZ1SH6ru4LOjoKGH84h6bggVtovL8qATK IzEG5EFms89Pkn7aB8IuH5+E/gp7z/+iY5tFWPn2S+2NICCXokiEGEWxg7G0jk4Tca fBBz53My8MsBUH9o9314+tFR1Wvk7qShV3iGWEiy7ptvfGrn8XqqjRart+BLP2XPG3 +MdexVjbaoe3A== Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:52:02 -0000 Rifaat, Thanks for looking into this. I think it is a good thing to do. I have a few comments: Is it your intent to change the *default* algorithm? Or simply to add new algorithms? You can't really change the default and remain backward compatible. If the intent is simply to add new algorithms, then ISTM that this can just be an extension to 3261. The IANA Considerations says: The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash Algorithms" to simplify the introduction of new algorithms in the future. This document will use the algorithms defined in that registry. The references don't define [HTTP-DIGEST]. The registry I was able to find is: https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml, and I found one draft that adds values to it: RFC 5843. But that rfc says: Note: This is unrelated to HTTP Digest Authentication. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. I find that RFC 2617 is the replacement for 2069, but it doesn't add algorithms or introduce a registry. Also, while you mention the registry in iana considerations, I don't see anything that discusses *use* of a registry. I also don't see anything that describes the use of the "-sess" suffix on the algorithm. (It is described in 3261, but solely for MD5-sess.) I think we could do the draft in such a way that it does utilize a registry for algorithms, either the one mentioned above or a new one. Thanks, Paul On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote: > Maybe I was not clear enough. > The draft is *not *deprecating MD5, but leaves it there for backward > compatibility. This is explained in the HTTP draft. > > The question is around the use of "qop" today which is optional in > RFC2617 and still under discussion in the HTTP draft to understand the > impact there. > > Regards, > Rifaat > > > On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson > wrote: > > > On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef > wrote: > >> Thanks Olle, >> >> See my replies inline... >> >> Regards, >> Rifaat >> >> >> >> On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson > > wrote: >> >> >> On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef >> > wrote: >> >>> Hi, >>> >>> >>> This draft, >>> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, >>> updates the Digest Authentication Scheme used by SIP based on >>> the ongoing update to the HTTP Digest Authentication Scheme >>> described here: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. >>> >>> >>> The document has one open issue related to the backward >>> compatibility with RFC2543/RFC2069. The backward >>> compatibility with RFC2069 in the HTTP document is still >>> under discussion. >>> >>> I would appreciate any feedback on this initial version of >>> this document. >>> >>> >> Great to see this finally happen! >> >> A few questions: >> >> 1. If you modify the BNF and other things - doesn't this >> update RFC 3261? >> >> >> Yes, I will add that to the next version of the draft. > Before Cullen says it: > > Do we have to update RFC3261 meaning that everyone is forced to > update to stay > compliant with SIP? Or can we do this as an optional addon? > > Moving forward and leaving MD5 behind is desirable, but maybe not > declaring devices > incompatible with SIP. What is the opinion of the SIPcore group? > >> >> 2. You state as an open issue whether we need to keep >> backwards compatibility >> with 2543/2069. What do you think, what would be the effect >> if we don't? >> >> >> That depends on what we have out there. >> Are there are many deployed systems that comply to RFC2543 but not >> RFC3261? >> Do most proxies add the "qop" parameter today? > Good question. Are proxys really allowed to mess with the > authentication headers? > > If we make this an optional specification, possibly with a supported > header, like > > Supported: strongauth > > then we can get rid of the old stuff. And maybe such a header would > help migration. > The server in that case doesn't have to downgrade to md5 and can > make a decision > on whether it requires this to proceed. > > Opinions? > > /O > >> >> >> 3. I would like to see a section that more clearly defines the >> changes compared >> with 3261/2543 to make it easier for developers to >> understand what they >> need to change and what they can keep. >> >> >> Ok. >> >> >> Cheers, >> /O >> >> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: ** >> > >>> Date: Fri, Jan 10, 2014 at 7:45 PM >>> Subject: New Version Notification for >>> draft-yusef-sipcore-digest-scheme-00.txt >>> To: Rifaat Shekh-Yusef >> > >>> >>> >>> >>> A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt >>> has been successfully submitted by Rifaat Shekh-Yusef and >>> posted to the >>> IETF repository. >>> >>> Name: draft-yusef-sipcore-digest-scheme >>> Revision: 00 >>> Title: The Session Initiation Protocol (SIP) Digest >>> Authentication Scheme >>> Document date: 2014-01-10 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 >>> >>> >>> Abstract: >>> This document updates the Digest Access Authentication >>> scheme used by >>> the Session Initiation Protocol (SIP) to add support for >>> SHA2 digest >>> algorithms to replace the MD5 algorithm. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the >>> time of submission >>> until the htmlized version and diff are available at >>> tools.ietf.org . >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Tue Jan 14 10:50:10 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC971AE24C for ; Tue, 14 Jan 2014 10:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fERSORv5X1B for ; Tue, 14 Jan 2014 10:50:07 -0800 (PST) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F37401AE24A for ; Tue, 14 Jan 2014 10:50:06 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id f15so3800eak.25 for ; Tue, 14 Jan 2014 10:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CefXqF+Ytygx4cV3v2GkTUVUpf9XJj+vrl5MtF1u+Z4=; b=T+9JYNkEwHc2V20IjTfa24wuWAv7tM6yONrlJ+gHAxnwZsWBcLoLcNvmWwIxeleKqL liyiVZqjl6rihnCZOQLiRfhEWv1ZJ3jBLgNnMWe65M7+SJ5ussgkHP0oDukmT5C0aFQU S6Z4urkEi13WDW9RaOkWFqeKXZ35AMzYJw94D2vn5hTsjtchJ51hy8H71UNzRDaXiU4J LpxoTjhQB44qDkRHzeJaTct4deaR+NFBCt5k3f8vGeDr2tZ91gkAE/Pyq2qVHvYaj6nB 43p6GbqxfvUT+2vMNjpqS5HBicWsefeapoQZfCfA0g2snzj+/QK1U+ONerpCe83F4jRn jDZA== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr3966437eew.61.1389725395122; Tue, 14 Jan 2014 10:49:55 -0800 (PST) Received: by 10.14.53.78 with HTTP; Tue, 14 Jan 2014 10:49:55 -0800 (PST) In-Reply-To: <52D57935.1070204@alum.mit.edu> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> Date: Tue, 14 Jan 2014 13:49:55 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c3fb7082fe1404eff2a8c8 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:50:10 -0000 --001a11c3fb7082fe1404eff2a8c8 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, Thanks for reviewing the document and for your comments. Please, see my reply inline... Regards, Rifaat On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat wrote: > Rifaat, > > Thanks for looking into this. I think it is a good thing to do. > I have a few comments: > > Is it your intent to change the *default* algorithm? Or simply to add new > algorithms? You can't really change the default and remain backward > compatible. > Yes, the idea is to make SHA2-256 as the default algorithm. The server is allowed to send multiple WWW-Authenticate headers with Digest schemes, but with different algorithms, as described in the HTTP Draft I have struggled with how much information I need to put in this draft. The current draft is minimalistic and relies on the HTTP draft to describe the mechanism in details. Is that ok? should I instead add more details to this draft that cover the operation of the new mechanism? > If the intent is simply to add new algorithms, then ISTM that this can > just be an extension to 3261. > > The IANA Considerations says: > > The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash > Algorithms" to simplify the introduction of new algorithms in the > future. This document will use the algorithms defined in that > registry. > > Sorry, I forgot to add the reference; this points to the following HTTP draft which is expected to obsolete RFC2617: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ The registry was added to the latest version of the draft and there was no final decision on how to proceed with this, as there were some ideas of pointing to other similar registries that might have some of these algorithms. The references don't define [HTTP-DIGEST]. The registry I was able to find > is: https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml, and > I found one draft that adds values to it: RFC 5843. But that rfc says: > > Note: This is unrelated to HTTP Digest Authentication. Instance > Digests in HTTP provide a digest, also known as a checksum or hash, > of an entire representation of the current state of a resource. > > I find that RFC 2617 is the replacement for 2069, but it doesn't add > algorithms or introduce a registry. > > Also, while you mention the registry in iana considerations, I don't see > anything that discusses *use* of a registry. > > I also don't see anything that describes the use of the "-sess" suffix on > the algorithm. (It is described in 3261, but solely for MD5-sess.) > > I do not think that the new algorithms will impact that aspect of the protocol. Do you? I think we could do the draft in such a way that it does utilize a registry > for algorithms, either the one mentioned above or a new one. > > Thanks, > Paul > > > On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote: > >> Maybe I was not clear enough. >> The draft is *not *deprecating MD5, but leaves it there for backward >> >> compatibility. This is explained in the HTTP draft. >> >> The question is around the use of "qop" today which is optional in >> RFC2617 and still under discussion in the HTTP draft to understand the >> impact there. >> >> Regards, >> Rifaat >> >> >> On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson > > wrote: >> >> >> On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef > > wrote: >> >> Thanks Olle, >>> >>> See my replies inline... >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson >> > wrote: >>> >>> >>> On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef >>> > wrote: >>> >>> Hi, >>>> >>>> >>>> This draft, >>>> https://datatracker.ietf.org/doc/draft-yusef-sipcore- >>>> digest-scheme/, >>>> updates the Digest Authentication Scheme used by SIP based on >>>> the ongoing update to the HTTP Digest Authentication Scheme >>>> described here: >>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/. >>>> >>>> >>>> The document has one open issue related to the backward >>>> compatibility with RFC2543/RFC2069. The backward >>>> compatibility with RFC2069 in the HTTP document is still >>>> under discussion. >>>> >>>> I would appreciate any feedback on this initial version of >>>> this document. >>>> >>>> >>>> Great to see this finally happen! >>> >>> A few questions: >>> >>> 1. If you modify the BNF and other things - doesn't this >>> update RFC 3261? >>> >>> >>> Yes, I will add that to the next version of the draft. >>> >> Before Cullen says it: >> >> Do we have to update RFC3261 meaning that everyone is forced to >> update to stay >> compliant with SIP? Or can we do this as an optional addon? >> >> Moving forward and leaving MD5 behind is desirable, but maybe not >> declaring devices >> incompatible with SIP. What is the opinion of the SIPcore group? >> >> >>> 2. You state as an open issue whether we need to keep >>> backwards compatibility >>> with 2543/2069. What do you think, what would be the effect >>> if we don't? >>> >>> >>> That depends on what we have out there. >>> Are there are many deployed systems that comply to RFC2543 but not >>> RFC3261? >>> Do most proxies add the "qop" parameter today? >>> >> Good question. Are proxys really allowed to mess with the >> authentication headers? >> >> If we make this an optional specification, possibly with a supported >> header, like >> >> Supported: strongauth >> >> then we can get rid of the old stuff. And maybe such a header would >> help migration. >> The server in that case doesn't have to downgrade to md5 and can >> make a decision >> on whether it requires this to proceed. >> >> Opinions? >> >> /O >> >> >>> >>> 3. I would like to see a section that more clearly defines the >>> changes compared >>> with 3261/2543 to make it easier for developers to >>> understand what they >>> need to change and what they can keep. >>> >>> >>> Ok. >>> >>> >>> Cheers, >>> /O >>> >>> >>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: ** >>> > >>>> Date: Fri, Jan 10, 2014 at 7:45 PM >>>> Subject: New Version Notification for >>>> draft-yusef-sipcore-digest-scheme-00.txt >>>> To: Rifaat Shekh-Yusef >>> > >>>> >>>> >>>> >>>> A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt >>>> has been successfully submitted by Rifaat Shekh-Yusef and >>>> posted to the >>>> IETF repository. >>>> >>>> Name: draft-yusef-sipcore-digest-scheme >>>> Revision: 00 >>>> Title: The Session Initiation Protocol (SIP) Digest >>>> Authentication Scheme >>>> Document date: 2014-01-10 >>>> Group: Individual Submission >>>> Pages: 7 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-yusef-sipcore- >>>> digest-scheme-00.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-yusef-sipcore- >>>> digest-scheme/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00 >>>> >>>> >>>> Abstract: >>>> This document updates the Digest Access Authentication >>>> scheme used by >>>> the Session Initiation Protocol (SIP) to add support for >>>> SHA2 digest >>>> algorithms to replace the MD5 algorithm. >>>> >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the >>>> time of submission >>>> until the htmlized version and diff are available at >>>> tools.ietf.org . >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c3fb7082fe1404eff2a8c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for reviewing the docum= ent and for your comments.
Please, see my reply inline...

Regards,
=A0Rifaat



On Tue, Jan 14, 2014 at 12:51 PM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
Rifaat,

Thanks for looking into this. I think it is a good thing to do.
I have a few comments:

Is it your intent to change the *default* algorithm? Or simply to add new a= lgorithms? You can't really change the default and remain backward comp= atible.

Yes, the idea is to make=A0SHA2-256 as t= he default algorithm.
The = server is allowed to send multiple=A0WWW-Authenticate headers with Digest schemes, bu= t with different=A0algorithms= , as described in the HTTP Draft
I have struggled with how much information I need to put in this = draft.
The current draft is minimalistic and relies on the HTTP d= raft to describe the mechanism in details. Is that ok? should I instead add= more details to this draft that cover the operation of the new mechanism?<= /div>


If the intent is simply to add new algorithms, then ISTM that this can just= be an extension to 3261.

The IANA Considerations says:

=A0 =A0The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest H= ash
=A0 =A0Algorithms" to simplify the introduction of new algorithms in t= he
=A0 =A0future. This document will use the algorithms defined in that
=A0 =A0registry.

Sorry, I forgot to add the reference; this points to = the following HTTP draft which is expected to obsolete RFC2617:
<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/">htt= ps://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

The registry was added to the latest version of t= he draft and there was no final decision on how to proceed with this, as th= ere were some ideas of pointing to other similar registries that might have= some of these algorithms.


The references don't define [HTTP-DIGEST]. =A0The registry I was able t= o find is: https://www.iana.org/assignments/http= -dig-alg/http-dig-alg.xhtml, and I found one draft that adds val= ues to it: RFC 5843. But that rfc says:

=A0 =A0Note: This is unrelated to HTTP Digest Authentication. =A0Instance =A0 =A0Digests in HTTP provide a digest, also known as a checksum or hash,<= br> =A0 =A0of an entire representation of the current state of a resource.

I find that RFC 2617 is the replacement for 2069, but it doesn't add al= gorithms or introduce a registry.

Also, while you mention the registry in iana considerations, I don't se= e anything that discusses *use* of a registry.

I also don't see anything that descri= bes the use of the "-sess" suffix on the algorithm. (It is descri= bed in 3261, but solely for MD5-sess.)

I do not think that the new algorithms will impact th= at aspect of the protocol. Do you?


I think we could do the draft in such a way that it does utilize a registry= for algorithms, either the one mentioned above or a new one.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote:
Maybe I was not clear enough.
The draft is *not *deprecating MD5, but leaves it there for backward

compatibility. This is explained in the HTTP draft.

The question is around the use of "qop" today which is optional i= n
RFC2617 and still under discussion in the HTTP draft to understand the
impact there.

Regards,
=A0 Rifaat


On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson <oej@edvina.net
<mailto:oej@edvina.n= et>> wrote:


=A0 =A0 On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
=A0 =A0 <mailto:rifaat.ietf@gmail.com>> wrote:

=A0 =A0 Thanks Olle,

=A0 =A0 See my replies inline...

=A0 =A0 Regards,
=A0 =A0 =A0Rifaat



=A0 =A0 On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson <oej@edvina.net
=A0 =A0 <mailto:oej@= edvina.net>> wrote:


=A0 =A0 =A0 =A0 On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef
=
=A0 =A0 =A0 =A0 <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
=A0 =A0 =A0 =A0 Hi,


=A0 =A0 =A0 =A0 This draft,
=A0 =A0 =A0 =A0 https://datatracker.ietf.org/= doc/draft-yusef-sipcore-digest-scheme/,
=A0 =A0 =A0 =A0 updates the Digest Authentication Scheme used by SIP based = on
=A0 =A0 =A0 =A0 the ongoing update to the HTTP Digest Authentication Scheme=
=A0 =A0 =A0 =A0 described here:
=A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/dra= ft-ietf-httpauth-digest/.


=A0 =A0 =A0 =A0 The document has one open issue related to the backward
=A0 =A0 =A0 =A0 compatibility with RFC2543/RFC2069. The backward
=A0 =A0 =A0 =A0 compatibility with RFC2069 in the HTTP document is still =A0 =A0 =A0 =A0 under discussion.

=A0 =A0 =A0 =A0 I would appreciate any feedback on this initial version of<= br> =A0 =A0 =A0 =A0 this document.


=A0 =A0 =A0 =A0 Great to see this finally happen!

=A0 =A0 =A0 =A0 A few questions:

=A0 =A0 =A0 =A0 1. If you modify the BNF and other things - doesn't thi= s
=A0 =A0 =A0 =A0 update RFC 3261?


=A0 =A0 Yes, I will add that to the next version of the draft.
=A0 =A0 Before Cullen says it:

=A0 =A0 Do we have to update RFC3261 meaning that everyone is forced to
=A0 =A0 update to stay
=A0 =A0 compliant with SIP? Or can we do this as an optional addon?

=A0 =A0 Moving forward and leaving MD5 behind is desirable, but maybe not =A0 =A0 declaring devices
=A0 =A0 incompatible with SIP. What is the opinion of the SIPcore group?

=A0 =A0 =A0 =A0 2. You state as an open issue whether we need to keep
=A0 =A0 =A0 =A0 backwards compatibility
=A0 =A0 =A0 =A0 =A0 =A0with 2543/2069. What do you think, what would be the= effect
=A0 =A0 =A0 =A0 if we don't?


=A0 =A0 That depends on what we have out there.
=A0 =A0 Are there are many deployed systems that comply to RFC2543 but not<= br> =A0 =A0 RFC3261?
=A0 =A0 Do most proxies add the "qop" parameter today?
=A0 =A0 Good question. Are proxys really allowed to mess with the
=A0 =A0 authentication headers?

=A0 =A0 If we make this an optional specification, possibly with a supporte= d
=A0 =A0 header, like

=A0 =A0 Supported: strongauth

=A0 =A0 then we can get rid of the old stuff. And maybe such a header would=
=A0 =A0 help migration.
=A0 =A0 The server in that case doesn't have to downgrade to md5 and ca= n
=A0 =A0 make a decision
=A0 =A0 on whether it requires this to proceed.

=A0 =A0 Opinions?

=A0 =A0 /O



=A0 =A0 =A0 =A0 3. I would like to see a section that more clearly defines = the
=A0 =A0 =A0 =A0 changes compared
=A0 =A0 =A0 =A0 =A0 =A0 with 3261/2543 to make it easier for developers to<= br> =A0 =A0 =A0 =A0 understand what they
=A0 =A0 =A0 =A0 =A0 =A0 need to change and what they can keep.


=A0 =A0 Ok.


=A0 =A0 =A0 =A0 Cheers,
=A0 =A0 =A0 =A0 /O


=A0 =A0 =A0 =A0 Regards,

=A0 =A0 =A0 =A0 =A0Rifaat



=A0 =A0 =A0 =A0 ---------- Forwarded message ----------
=A0 =A0 =A0 =A0 From: ** <internet-drafts@ietf.org
=A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>
=A0 =A0 =A0 =A0 Date: Fri, Jan 10, 2014 at 7:45 PM
=A0 =A0 =A0 =A0 Subject: New Version Notification for
=A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme-00.txt
=A0 =A0 =A0 =A0 To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com
=A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com>>



=A0 =A0 =A0 =A0 A new version of I-D, draft-yusef-sipcore-digest-sch= eme-00.txt
=A0 =A0 =A0 =A0 has been successfully submitted by Rifaat Shekh-Yusef and =A0 =A0 =A0 =A0 posted to the
=A0 =A0 =A0 =A0 IETF repository.

=A0 =A0 =A0 =A0 Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
=A0 =A0 =A0 =A0 Revision: =A0 =A0 =A0 00
=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (= SIP) Digest
=A0 =A0 =A0 =A0 Authentication Scheme
=A0 =A0 =A0 =A0 Document date: =A02014-01-10
=A0 =A0 =A0 =A0 Group: =A0 =A0 =A0 =A0 =A0Individual Submission
=A0 =A0 =A0 =A0 Pages: =A0 =A0 =A0 =A0 =A07
=A0 =A0 =A0 =A0 URL:
=A0 =A0 =A0 =A0 http://www.ietf.org/interne= t-drafts/draft-yusef-sipcore-digest-scheme-00.txt
=A0 =A0 =A0 =A0 Status:
=A0 =A0 =A0 =A0 https://datatracker.ietf.org/= doc/draft-yusef-sipcore-digest-scheme/
=A0 =A0 =A0 =A0 Htmlized:
=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-= yusef-sipcore-digest-scheme-00


=A0 =A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0 =A0This document updates the Digest Access Authenticati= on
=A0 =A0 =A0 =A0 scheme used by
=A0 =A0 =A0 =A0 =A0 =A0the Session Initiation Protocol (SIP) to add support= for
=A0 =A0 =A0 =A0 SHA2 digest
=A0 =A0 =A0 =A0 =A0 =A0algorithms to replace the MD5 algorithm.





=A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the =A0 =A0 =A0 =A0 time of submission
=A0 =A0 =A0 =A0 until the htmlized version and diff are available at
=A0 =A0 =A0 =A0 tools.i= etf.org <http:/= /tools.ietf.org/>.


=A0 =A0 =A0 =A0 The IETF Secretariat


=A0 =A0 =A0 =A0 _______________________________________________
=A0 =A0 =A0 =A0 sipcore mailing list
=A0 =A0 =A0 =A0 sipco= re@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore


=A0 =A0 _______________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore




_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c3fb7082fe1404eff2a8c8-- From ibc@aliax.net Tue Jan 14 15:04:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271431AE2D2 for ; Tue, 14 Jan 2014 15:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg8pcWo1xKUT for ; Tue, 14 Jan 2014 15:04:46 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFDE1AE22E for ; Tue, 14 Jan 2014 15:04:46 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so284277qac.0 for ; Tue, 14 Jan 2014 15:04:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=1fdGdCY9FeMzw4XtutC/KHPJrR8/RuzBI9ye4kl2N8I=; b=HgW+6s/zXMbe8nfwURO+vZ9oKtEemD4RGGEr1SxRnKPSwU3EWaT6+iLEjq+uLNVe2u sAOpEAFuEdXTj0BjZXtqWuyn0/XSJ8X4gbjPT9lQUU4tKTixLq21UUZI7JMh1mBmoMZk JgnQX8f8MvuAmtYcgOkVZymCWJUwXfLrxCHAJOSWfGgrKAa3hy6VyANQjaETWjIvDMVN pIMT+J0yrnTBI+uidQtfgtWVLtOVf/1xaM8lSpCW0lNl7+lybWMKDS0D3pLXVPwPpfYO FuEfLPlNy6rMNncKnmXLQO5Vx5761k2I/neON5wE9kOXd4lYbBZni1OnpnWM6O3gJCrz CAEw== X-Gm-Message-State: ALoCoQl5K6EsfVKjOov3wgGPALZHruBsC5IvrWOYXkNKQ5HUtYlmxfUHsglHub7bowL76x/dqqry X-Received: by 10.49.110.72 with SMTP id hy8mr7563283qeb.67.1389740674832; Tue, 14 Jan 2014 15:04:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.82.97 with HTTP; Tue, 14 Jan 2014 15:04:14 -0800 (PST) In-Reply-To: References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 15 Jan 2014 00:04:14 +0100 Message-ID: To: Rifaat Shekh-Yusef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:04:48 -0000 2014/1/14 Rifaat Shekh-Yusef : > Yes, the idea is to make SHA2-256 as the default algorithm. > The server is allowed to send multiple WWW-Authenticate headers with Dige= st > schemes, but with different algorithms, as described in the HTTP Draft > I have struggled with how much information I need to put in this draft. Hi, let me understand: Do you mean that if a SIP UA receives a 401 response with multiple WWW-Authenticate headers (having all of them the same realm,) the UA should be able to select one of them (i.e. the one with an algorithm that the UA supports)? Is it that documented by RFC 2617 or 3261? Another question (assuming "yes" is the response to the above questions): Are today's SIP UAs really ready to receive multiple WWW-Authenticate headers (same realm) and select the "best" one? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From rifaat.ietf@gmail.com Tue Jan 14 15:55:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB61D1AE11F for ; Tue, 14 Jan 2014 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAbAHSklJeEu for ; Tue, 14 Jan 2014 15:55:44 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0F1AE0E3 for ; Tue, 14 Jan 2014 15:55:43 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id c13so450433eek.33 for ; Tue, 14 Jan 2014 15:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XwTFMB5naq3kEYYTkdrryoJcwxFoXz1UCjylNkv5BvI=; b=P9AJbXqAJmqz2D2vUKH2i6obJ8horiT+WI8E5QNIMKBqdc0Uo5wvoLUI84hf05KGtm V1AzFgO1wWzLZW+zPAe7fYolBU3orij5hrYb9fVh0Un5tZ4GEdctX2kLJgoivWSnmL8r N2Le0YLUQKMj6Cp704SXcm+wFi8aOdIOeZntWiLsDuq+gcFC5T8cU86KRNCXhjvJkXhI mPnuyCHfWSt3QTZVBdmqQYOs5BCNdgwSRE1KksWmmRdUREYGW43eu+c6mrCCNPLhfliP YWvdvRLVylWKo1ZVaX+yn3jN37YXDkMTHY/3Zn4z3wyRIL8+JT2X8LRGcpVonJuj/6Xk IgEA== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr5212744eew.61.1389743732088; Tue, 14 Jan 2014 15:55:32 -0800 (PST) Received: by 10.14.53.78 with HTTP; Tue, 14 Jan 2014 15:55:32 -0800 (PST) In-Reply-To: References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> Date: Tue, 14 Jan 2014 18:55:32 -0500 Message-ID: From: Rifaat Shekh-Yusef To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c3fb707ae2b204eff6edac Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:55:45 -0000 --001a11c3fb707ae2b204eff6edac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi I=F1aki, Please, see my reply inline... Regards, Rifaat On Tue, Jan 14, 2014 at 6:04 PM, I=F1aki Baz Castillo wrote= : > 2014/1/14 Rifaat Shekh-Yusef : > > Yes, the idea is to make SHA2-256 as the default algorithm. > > The server is allowed to send multiple WWW-Authenticate headers with > Digest > > schemes, but with different algorithms, as described in the HTTP Draft > > I have struggled with how much information I need to put in this draft. > > Hi, let me understand: Do you mean that if a SIP UA receives a 401 > response with multiple WWW-Authenticate headers (having all of them > the same realm,) the UA should be able to select one of them (i.e. the > one with an algorithm that the UA supports)? > > Yes. Is it that documented by RFC 2617 or 3261? > > Yes. The following is a quote from RFC2617: Note: User agents will need to take special care in parsing the WWW- Authenticate or Proxy-Authenticate header field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters. The new HTTP draft makes this more explicit. Another question (assuming "yes" is the response to the above > questions): Are today's SIP UAs really ready to receive multiple > WWW-Authenticate headers (same realm) and select the "best" one? > > They should, according to the above quote from RFC2617. We had the same question with regards to the browsers and it turned out that the browsers were able to handle it properly; browsers give preference to the header that appears first. > Thanks a lot. > > > -- > I=F1aki Baz Castillo > > --001a11c3fb707ae2b204eff6edac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi I=F1aki,

Please, see my reply inline= ...

Regards,
=A0Rifaat

On T= ue, Jan 14, 2014 at 6:04 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2014/1/14 Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:
> Yes, the idea is to make SHA2-256 as the default alg= orithm.
> The server is allowed to send multiple WWW-Authenticate headers with D= igest
> schemes, but with different algorithms, as described in the HTTP Draft=
> I have struggled with how much information I need to put in this draft= .

Hi, let me understand: Do you mean that if a SIP UA receives a 401 response with multiple WWW-Authenticate headers (having all of them
the same realm,) the UA should be able to select one of them (i.e. the
one with an algorithm that the UA supports)?

Yes.
=A0

Is it that documented by RFC 2617 or 3261?

Yes. The following is a quote from RFC2617:
= 

   Note: User agents will need to take special care in p=
arsing the WWW-
   Authenticate or Proxy-Authenticate header field value if it contains
   more than one challenge, or if more than one WWW-Authenticate header
   field is provided, since the contents of a challenge may itself
   contain a comma-separated list of authentication parameters.
The new HTTP draft makes thi=
s more explicit.
<=
span style=3D"font-family:arial;color:rgb(34,34,34)">
Another question (assuming "yes" is the response to the above
questions): Are today's SIP UAs really ready to receive multiple
WWW-Authenticate headers (same realm) and select the "best" one?<= br>

They should, according to the above qu= ote from RFC2617.=A0
We had the same question with regards to the= browsers and it turned out that the browsers were able to handle it proper= ly; browsers give preference to the header that appears first.

=A0
Thanks a lot.


--
I=F1aki Baz Castillo
<ibc@aliax.net>

--001a11c3fb707ae2b204eff6edac-- From pkyzivat@alum.mit.edu Tue Jan 14 15:57:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD111AE01C for ; Tue, 14 Jan 2014 15:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sfDOD5aZiRS for ; Tue, 14 Jan 2014 15:57:53 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id A75EE1ADFA0 for ; Tue, 14 Jan 2014 15:57:52 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id DyMK1n0020QuhwU57zxgtg; Tue, 14 Jan 2014 23:57:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Dzxg1n0073ZTu2S3NzxgGq; Tue, 14 Jan 2014 23:57:40 +0000 Message-ID: <52D5CEF4.5010408@alum.mit.edu> Date: Tue, 14 Jan 2014 18:57:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389743860; bh=EdFza+drNoWxTbJwEeHajDpiBLg/hltMFrr8wvnip90=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PQADdLKMChhOW5awO+o/5Mts3naKWaPEF7l2LE7mvrCG4qf4giC5Fj8crPaM0Qd9Q RbyeuMA0uPks/VHE1h8tiRL4j11fMQxj3rZ0mcWJCAKkYrJc1Jqu7Uzhk2xA4yMP8y rR0tDWNfaks8vg7GSdAUh3s1+coemJxSJECLkqj/NXQq96qh2pkBp7Xwnrb4vSu0v4 tF6TMVAOsE2WijIGWcYv7nA47RtATHvMn7+yQtaN95bnMl3gAZjmpP6YQSgwEqTBdz q6U6E6TSPO1Vp8NoWSxqH0Aro88ioVC4VEmj0maTZRwfQbW6xEnwI4FziN1qIJ8LWk EfPlVTa2zFHOQ== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:57:55 -0000 Inline... On 1/14/14 1:49 PM, Rifaat Shekh-Yusef wrote: > Hi Paul, > > Thanks for reviewing the document and for your comments. > Please, see my reply inline... > > Regards, > Rifaat > > > > On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat > wrote: > > Rifaat, > > Thanks for looking into this. I think it is a good thing to do. > I have a few comments: > > Is it your intent to change the *default* algorithm? Or simply to > add new algorithms? You can't really change the default and remain > backward compatible. > > > Yes, the idea is to make SHA2-256 as the default algorithm. IIUC, previously (according to 2543 and 3261) MD5 is used if no algorithm is specified. And you would propose to change the default in that case. How can that possibly work in a backward compatible way??? I think you can *deprecate* MD5, but not change the default. That means that anything conforming to this extension/revision MUST specify an algorithm, and not MD5. But it still isn't a default. > The server is allowed to send multiple WWW-Authenticate headers with > Digest schemes, but with different algorithms, as described in the HTTP > Draft > I have struggled with how much information I need to put in this draft. > The current draft is minimalistic and relies on the HTTP draft to > describe the mechanism in details. Is that ok? should I instead add more > details to this draft that cover the operation of the new mechanism? I think it is too minimal. I haven't yet read [HTTP-DIGEST], but I doubt it will be sufficient. > If the intent is simply to add new algorithms, then ISTM that this > can just be an extension to 3261. > > The IANA Considerations says: > > The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash > Algorithms" to simplify the introduction of new algorithms in the > future. This document will use the algorithms defined in that > registry. > > Sorry, I forgot to add the reference; this points to the following HTTP > draft which is expected to obsolete RFC2617: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ OK. I'll have to check that out. > The registry was added to the latest version of the draft and there was > no final decision on how to proceed with this, as there were some ideas > of pointing to other similar registries that might have some of these > algorithms. I guess you propose to use the same registry for SIP? > The references don't define [HTTP-DIGEST]. The registry I was able > to find is: > https://www.iana.org/__assignments/http-dig-alg/http-__dig-alg.xhtml > , > and I found one draft that adds values to it: RFC 5843. But that rfc > says: > > Note: This is unrelated to HTTP Digest Authentication. Instance > Digests in HTTP provide a digest, also known as a checksum or hash, > of an entire representation of the current state of a resource. > > I find that RFC 2617 is the replacement for 2069, but it doesn't add > algorithms or introduce a registry. > > Also, while you mention the registry in iana considerations, I don't > see anything that discusses *use* of a registry. > > I also don't see anything that describes the use of the "-sess" > suffix on the algorithm. (It is described in 3261, but solely for > MD5-sess.) > > I do not think that the new algorithms will impact that aspect of the > protocol. Do you? I just took a peek at [HTTP-DIGEST], and see that it defines the "-sess" variations. It appears to me that every algorithm is likely to have a "-sess" variant, and the relationship between the two is likely to be the same. Do you really want every new algorithm that is registered to be required to redefine a "-sess" variant? Or could a generic way be defined for deriving a "-sess" variant from an arbitrary algorithm. > I think we could do the draft in such a way that it does utilize a > registry for algorithms, either the one mentioned above or a new one. > > Thanks, > Paul > > > On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote: > > Maybe I was not clear enough. > The draft is *not *deprecating MD5, but leaves it there for backward > > compatibility. This is explained in the HTTP draft. > > The question is around the use of "qop" today which is optional in > RFC2617 and still under discussion in the HTTP draft to > understand the > impact there. > > Regards, > Rifaat > > > On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson > > >> wrote: > > > On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef > > >__> wrote: > > Thanks Olle, > > See my replies inline... > > Regards, > Rifaat > > > > On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson > > >> wrote: > > > On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef > >__> wrote: > > Hi, > > > This draft, > https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/ > , > updates the Digest Authentication Scheme used > by SIP based on > the ongoing update to the HTTP Digest > Authentication Scheme > described here: > https://datatracker.ietf.org/__doc/draft-ietf-httpauth-__digest/ > . > > > The document has one open issue related to the > backward > compatibility with RFC2543/RFC2069. The backward > compatibility with RFC2069 in the HTTP document > is still > under discussion. > > I would appreciate any feedback on this initial > version of > this document. > > > Great to see this finally happen! > > A few questions: > > 1. If you modify the BNF and other things - doesn't > this > update RFC 3261? > > > Yes, I will add that to the next version of the draft. > > Before Cullen says it: > > Do we have to update RFC3261 meaning that everyone is forced to > update to stay > compliant with SIP? Or can we do this as an optional addon? > > Moving forward and leaving MD5 behind is desirable, but > maybe not > declaring devices > incompatible with SIP. What is the opinion of the SIPcore > group? > > > 2. You state as an open issue whether we need to keep > backwards compatibility > with 2543/2069. What do you think, what would be > the effect > if we don't? > > > That depends on what we have out there. > Are there are many deployed systems that comply to > RFC2543 but not > RFC3261? > Do most proxies add the "qop" parameter today? > > Good question. Are proxys really allowed to mess with the > authentication headers? > > If we make this an optional specification, possibly with a > supported > header, like > > Supported: strongauth > > then we can get rid of the old stuff. And maybe such a > header would > help migration. > The server in that case doesn't have to downgrade to md5 > and can > make a decision > on whether it requires this to proceed. > > Opinions? > > /O > > > > 3. I would like to see a section that more clearly > defines the > changes compared > with 3261/2543 to make it easier for developers to > understand what they > need to change and what they can keep. > > > Ok. > > > Cheers, > /O > > > Regards, > > Rifaat > > > > ---------- Forwarded message ---------- > From: ** > >> > Date: Fri, Jan 10, 2014 at 7:45 PM > Subject: New Version Notification for > draft-yusef-sipcore-digest-__scheme-00.txt > To: Rifaat Shekh-Yusef > >__> > > > > A new version of I-D, > draft-yusef-sipcore-digest-__scheme-00.txt > has been successfully submitted by Rifaat > Shekh-Yusef and > posted to the > IETF repository. > > Name: draft-yusef-sipcore-digest-__scheme > Revision: 00 > Title: The Session Initiation Protocol > (SIP) Digest > Authentication Scheme > Document date: 2014-01-10 > Group: Individual Submission > Pages: 7 > URL: > http://www.ietf.org/internet-__drafts/draft-yusef-sipcore-__digest-scheme-00.txt > > Status: > https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/ > > Htmlized: > http://tools.ietf.org/html/__draft-yusef-sipcore-digest-__scheme-00 > > > > Abstract: > This document updates the Digest Access > Authentication > scheme used by > the Session Initiation Protocol (SIP) to add > support for > SHA2 digest > algorithms to replace the MD5 algorithm. > > > > > > Please note that it may take a couple of > minutes from the > time of submission > until the htmlized version and diff are > available at > tools.ietf.org > . > > > The IETF Secretariat > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > > > https://www.ietf.org/mailman/__listinfo/sipcore > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > > > https://www.ietf.org/mailman/__listinfo/sipcore > > > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From rifaat.ietf@gmail.com Tue Jan 14 16:38:03 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CB91AE194 for ; Tue, 14 Jan 2014 16:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj3GZ8a2eDnQ for ; Tue, 14 Jan 2014 16:37:59 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 628C81ADF47 for ; Tue, 14 Jan 2014 16:37:58 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so139052ead.6 for ; Tue, 14 Jan 2014 16:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kGY4a0Z7VyQz0UPso40TRnw4AMwzXleg3CCqrSMyicA=; b=EZTDYnY9KHZ+bPjLZrRHC53jvint/8/NvKXy/SyXHueU3AbLxSdR32QI6TFDANF3Cr XwAAFkE5Z3xSzWBqpd7rc9Ylg6NADfrohZZgLZPp1x5a70FM0ja4oGzZ5R/tPnfjMSWk EWYb1dcLg0ISHqemI5EzvIuDvdDGKk4TvDTckvJOCtAGZldLrcdab/6rmxGkftdmOGkl AfjE0pi4wKItWXc8HT606Wf2itvnXVm4S8tNxYLPvzt9a3egbuekbrRkQxR35NJWG8/R 6/+WFQ9Xt77YVUC7gOHkRc8ec6cI7YnapkGAKk1mBrUxpAarwWEssx12+Tu4FXsSq4/2 nuzA== MIME-Version: 1.0 X-Received: by 10.14.203.6 with SMTP id e6mr5428293eeo.33.1389746266409; Tue, 14 Jan 2014 16:37:46 -0800 (PST) Received: by 10.14.53.78 with HTTP; Tue, 14 Jan 2014 16:37:46 -0800 (PST) In-Reply-To: <52D5CEF4.5010408@alum.mit.edu> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> <52D5CEF4.5010408@alum.mit.edu> Date: Tue, 14 Jan 2014 19:37:46 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b33db06898f0404eff78408 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 00:38:03 -0000 --047d7b33db06898f0404eff78408 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Tue, Jan 14, 2014 at 6:57 PM, Paul Kyzivat wrote: > Inline... > > > On 1/14/14 1:49 PM, Rifaat Shekh-Yusef wrote: > >> Hi Paul, >> >> Thanks for reviewing the document and for your comments. >> Please, see my reply inline... >> >> Regards, >> Rifaat >> >> >> >> On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat > > wrote: >> >> Rifaat, >> >> Thanks for looking into this. I think it is a good thing to do. >> I have a few comments: >> >> Is it your intent to change the *default* algorithm? Or simply to >> add new algorithms? You can't really change the default and remain >> backward compatible. >> >> >> Yes, the idea is to make SHA2-256 as the default algorithm. >> > > IIUC, previously (according to 2543 and 3261) MD5 is used if no algorithm > is specified. And you would propose to change the default in that case. > > How can that possibly work in a backward compatible way??? > > I think you can *deprecate* MD5, but not change the default. That means > that anything conforming to this extension/revision MUST specify an > algorithm, and not MD5. But it still isn't a default. > > I see what you saying. I need to think about how to change the text to not state that we are changing the default, but still prefer SHA2-256. > > The server is allowed to send multiple WWW-Authenticate headers with >> Digest schemes, but with different algorithms, as described in the HTTP >> Draft >> I have struggled with how much information I need to put in this draft. >> The current draft is minimalistic and relies on the HTTP draft to >> describe the mechanism in details. Is that ok? should I instead add more >> details to this draft that cover the operation of the new mechanism? >> > > I think it is too minimal. I haven't yet read [HTTP-DIGEST], but I doubt > it will be sufficient. > > > If the intent is simply to add new algorithms, then ISTM that this >> can just be an extension to 3261. >> >> The IANA Considerations says: >> >> The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash >> Algorithms" to simplify the introduction of new algorithms in the >> future. This document will use the algorithms defined in that >> registry. >> >> Sorry, I forgot to add the reference; this points to the following HTTP >> draft which is expected to obsolete RFC2617: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >> > > OK. I'll have to check that out. > > > The registry was added to the latest version of the draft and there was >> no final decision on how to proceed with this, as there were some ideas >> of pointing to other similar registries that might have some of these >> algorithms. >> > > I guess you propose to use the same registry for SIP? > > Yes > The references don't define [HTTP-DIGEST]. The registry I was able >> to find is: >> https://www.iana.org/__assignments/http-dig-alg/http-__dig-alg.xhtml >> , >> >> and I found one draft that adds values to it: RFC 5843. But that rfc >> says: >> >> Note: This is unrelated to HTTP Digest Authentication. Instance >> Digests in HTTP provide a digest, also known as a checksum or >> hash, >> of an entire representation of the current state of a resource. >> >> I find that RFC 2617 is the replacement for 2069, but it doesn't add >> algorithms or introduce a registry. >> >> Also, while you mention the registry in iana considerations, I don't >> see anything that discusses *use* of a registry. >> >> I also don't see anything that describes the use of the "-sess" >> suffix on the algorithm. (It is described in 3261, but solely for >> MD5-sess.) >> >> I do not think that the new algorithms will impact that aspect of the >> protocol. Do you? >> > > I just took a peek at [HTTP-DIGEST], and see that it defines the "-sess" > variations. > > It appears to me that every algorithm is likely to have a "-sess" variant, > and the relationship between the two is likely to be the same. Do you > really want every new algorithm that is registered to be required to > redefine a "-sess" variant? Or could a generic way be defined for deriving > a "-sess" variant from an arbitrary algorithm. > > Good point. I will change it in the next version of the draft. Thanks, Rifaat > I think we could do the draft in such a way that it does utilize a >> registry for algorithms, either the one mentioned above or a new one. >> >> Thanks, >> Paul >> >> >> On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote: >> >> Maybe I was not clear enough. >> The draft is *not *deprecating MD5, but leaves it there for >> backward >> >> compatibility. This is explained in the HTTP draft. >> >> The question is around the use of "qop" today which is optional in >> RFC2617 and still under discussion in the HTTP draft to >> understand the >> impact there. >> >> Regards, >> Rifaat >> >> >> On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson >> >> >> wrote: >> >> >> On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef >> >> > >> >__> wrote: >> >> Thanks Olle, >> >> See my replies inline... >> >> Regards, >> Rifaat >> >> >> >> On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson >> >> >> wrote: >> >> >> On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef >> > > >> >__> wrote: >> >> Hi, >> >> >> This draft, >> https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__ >> digest-scheme/ >> > digest-scheme/>, >> >> updates the Digest Authentication Scheme used >> by SIP based on >> the ongoing update to the HTTP Digest >> Authentication Scheme >> described here: >> https://datatracker.ietf.org/__doc/draft-ietf-httpauth-__ >> digest/ >> > digest/>. >> >> >> >> The document has one open issue related to the >> backward >> compatibility with RFC2543/RFC2069. The backward >> compatibility with RFC2069 in the HTTP document >> is still >> under discussion. >> >> I would appreciate any feedback on this initial >> version of >> this document. >> >> >> Great to see this finally happen! >> >> A few questions: >> >> 1. If you modify the BNF and other things - doesn't >> this >> update RFC 3261? >> >> >> Yes, I will add that to the next version of the draft. >> >> Before Cullen says it: >> >> Do we have to update RFC3261 meaning that everyone is forced >> to >> update to stay >> compliant with SIP? Or can we do this as an optional addon? >> >> Moving forward and leaving MD5 behind is desirable, but >> maybe not >> declaring devices >> incompatible with SIP. What is the opinion of the SIPcore >> group? >> >> >> 2. You state as an open issue whether we need to keep >> backwards compatibility >> with 2543/2069. What do you think, what would be >> the effect >> if we don't? >> >> >> That depends on what we have out there. >> Are there are many deployed systems that comply to >> RFC2543 but not >> RFC3261? >> Do most proxies add the "qop" parameter today? >> >> Good question. Are proxys really allowed to mess with the >> authentication headers? >> >> If we make this an optional specification, possibly with a >> supported >> header, like >> >> Supported: strongauth >> >> then we can get rid of the old stuff. And maybe such a >> header would >> help migration. >> The server in that case doesn't have to downgrade to md5 >> and can >> make a decision >> on whether it requires this to proceed. >> >> Opinions? >> >> /O >> >> >> >> 3. I would like to see a section that more clearly >> defines the >> changes compared >> with 3261/2543 to make it easier for developers >> to >> understand what they >> need to change and what they can keep. >> >> >> Ok. >> >> >> Cheers, >> /O >> >> >> Regards, >> >> Rifaat >> >> >> >> ---------- Forwarded message ---------- >> From: ** > >> > >> >> Date: Fri, Jan 10, 2014 at 7:45 PM >> Subject: New Version Notification for >> draft-yusef-sipcore-digest-__scheme-00.txt >> To: Rifaat Shekh-Yusef > >> > >__> >> >> >> >> >> A new version of I-D, >> draft-yusef-sipcore-digest-__scheme-00.txt >> >> has been successfully submitted by Rifaat >> Shekh-Yusef and >> posted to the >> IETF repository. >> >> Name: draft-yusef-sipcore-digest-__ >> scheme >> >> Revision: 00 >> Title: The Session Initiation Protocol >> (SIP) Digest >> Authentication Scheme >> Document date: 2014-01-10 >> Group: Individual Submission >> Pages: 7 >> URL: >> http://www.ietf.org/internet-_ >> _drafts/draft-yusef-sipcore-__digest-scheme-00.txt >> > digest-scheme-00.txt> >> Status: >> https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__ >> digest-scheme/ >> > digest-scheme/> >> Htmlized: >> http://tools.ietf.org/html/__ >> draft-yusef-sipcore-digest-__scheme-00 >> >> > scheme-00> >> >> >> Abstract: >> This document updates the Digest Access >> Authentication >> scheme used by >> the Session Initiation Protocol (SIP) to add >> support for >> SHA2 digest >> algorithms to replace the MD5 algorithm. >> >> >> >> >> >> Please note that it may take a couple of >> minutes from the >> time of submission >> until the htmlized version and diff are >> available at >> tools.ietf.org >> . >> >> >> The IETF Secretariat >> >> >> ______________________________ >> ___________________ >> >> sipcore mailing list >> sipcore@ietf.org >> > >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> >> _________________________________________________ >> >> sipcore mailing list >> sipcore@ietf.org >> > >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> >> >> >> _________________________________________________ >> >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> _________________________________________________ >> >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> > --047d7b33db06898f0404eff78408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Tue, Jan 14, 2014 at 6:57 PM, Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:
Inline...


On 1/14/14 1:49 PM, Rifaat Shekh-Yusef wrote:
Hi Paul,

Thanks for reviewing the document and for your comments.
Please, see my reply inline...

Regards,
=A0 Rifaat



On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 Rifaat,

=A0 =A0 Thanks for looking into this. I think it is a good thing to do.
=A0 =A0 I have a few comments:

=A0 =A0 Is it your intent to change the *default* algorithm? Or simply to =A0 =A0 add new algorithms? You can't really change the default and rem= ain
=A0 =A0 backward compatible.


Yes, the idea is to make SHA2-256 as the default algorithm.

IIUC, previously (according to 2543 and 3261) MD5 is used if no algorithm i= s specified. And you would propose to change the default in that case.

How can that possibly work in a backward compatible way???

I think you can *deprecate* MD5, but not change the default. That means tha= t anything conforming to this extension/revision MUST specify an algorithm,= and not MD5. But it still isn't a default.


I see what you saying. I need to think abo= ut how to change the text to not state that we are changing the default, bu= t still prefer SHA2-256.

=A0

The server is allowed to send multiple WWW-Authenticate headers with
Digest schemes, but with different algorithms, as described in the HTTP
Draft
I have struggled with how much information I need to put in this draft.
The current draft is minimalistic and relies on the HTTP draft to
describe the mechanism in details. Is that ok? should I instead add more details to this draft that cover the operation of the new mechanism?

I think it is too minimal. I haven't yet read [HTTP-DIGEST], but I doub= t it will be sufficient.


=A0 =A0 If the intent is simply to add new algorithms, then ISTM that this<= br> =A0 =A0 can just be an extension to 3261.

=A0 =A0 The IANA Considerations says:

=A0 =A0 =A0 =A0 The [HTTP-DIGEST] defines an IANA registry named "HTTP= Digest Hash
=A0 =A0 =A0 =A0 Algorithms" to simplify the introduction of new algori= thms in the
=A0 =A0 =A0 =A0 future. This document will use the algorithms defined in th= at
=A0 =A0 =A0 =A0 registry.

Sorry, I forgot to add the reference; this points to the following HTTP
draft which is expected to obsolete RFC2617:
https://datatracker.ietf.org/doc/draft-ietf-httpauth= -digest/

OK. I'll have to check that out.


The registry was added to the latest version of the draft and there was
no final decision on how to proceed with this, as there were some ideas
of pointing to other similar registries that might have some of these
algorithms.

I guess you propose to use the same registry for SIP?


Yes

=A0
=A0 =A0 The references don't define [HTTP-DIGEST]. =A0The registry I wa= s able
=A0 =A0 to find is:
=A0 =A0 https://www.iana.org/__assignments/h= ttp-dig-alg/http-__dig-alg.xhtml
=A0 =A0 <https://www.iana.org/assignments/htt= p-dig-alg/http-dig-alg.xhtml>,

=A0 =A0 and I found one draft that adds values to it: RFC 5843. But that rf= c
=A0 =A0 says:

=A0 =A0 =A0 =A0 Note: This is unrelated to HTTP Digest Authentication. =A0I= nstance
=A0 =A0 =A0 =A0 Digests in HTTP provide a digest, also known as a checksum = or hash,
=A0 =A0 =A0 =A0 of an entire representation of the current state of a resou= rce.

=A0 =A0 I find that RFC 2617 is the replacement for 2069, but it doesn'= t add
=A0 =A0 algorithms or introduce a registry.

=A0 =A0 Also, while you mention the registry in iana considerations, I don&= #39;t
=A0 =A0 see anything that discusses *use* of a registry.

=A0 =A0 I also don't see anything that describes the use of the "-= sess"
=A0 =A0 suffix on the algorithm. (It is described in 3261, but solely for =A0 =A0 MD5-sess.)

I do not think that the new algorithms will impact that aspect of the
protocol. Do you?

I just took a peek at [HTTP-DIGEST], and see that it defines the "-ses= s" variations.

It appears to me that every algorithm is likely to have a "-sess"= variant, and the relationship between the two is likely to be the same. Do= you really want every new algorithm that is registered to be required to r= edefine a "-sess" variant? Or could a generic way be defined for = deriving a "-sess" variant from an arbitrary algorithm.


Good point. I will change it in the ne= xt version of the draft.

Thanks,
=A0Rifa= at


=A0
=A0 =A0 I think we could do the draft in such a way that it does utilize a<= br> =A0 =A0 registry for algorithms, either the one mentioned above or a new on= e.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul


=A0 =A0 On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote:

=A0 =A0 =A0 =A0 Maybe I was not clear enough.
=A0 =A0 =A0 =A0 The draft is *not *deprecating MD5, but leaves it there for= backward

=A0 =A0 =A0 =A0 compatibility. This is explained in the HTTP draft.

=A0 =A0 =A0 =A0 The question is around the use of "qop" today whi= ch is optional in
=A0 =A0 =A0 =A0 RFC2617 and still under discussion in the HTTP draft to
=A0 =A0 =A0 =A0 understand the
=A0 =A0 =A0 =A0 impact there.

=A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0Rifaat


=A0 =A0 =A0 =A0 On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson
=A0 =A0 =A0 =A0 <oej= @edvina.net <mailto:oej@edvina.net>
=A0 =A0 =A0 =A0 <mailto:oej@edvina.net <mailto:oej@edvina.net>>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>
=A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:rifaat.ietf@gmail.com

=A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com>>__> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks Olle,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0See my replies inline...

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rifaat



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On Sat, Jan 11, 2014 at 5:51 AM, Olle E.= Johansson
=A0 =A0 =A0 =A0 =A0 =A0 <oej@edvina.net <mailto:oej@edvina.net>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:oej@edvina.net <mailto:oej@edvina.net>>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 11 Jan 2014, at 01:48, Rifaat= Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<rifaat.ietf@gmail.com
=A0 =A0 =A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com> <mailto:rifaat.ietf@gmail.com

=A0 =A0 =A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com>>__> wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi,


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This draft,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://datatrac= ker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://datatrac= ker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/>,<= div class=3D"im">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0updates the Digest Authe= ntication Scheme used
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 by SIP based on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the ongoing update to th= e HTTP Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authentication Scheme
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0described here:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://datatracker.iet= f.org/__doc/draft-ietf-httpauth-__digest/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://datatracker.iet= f.org/doc/draft-ietf-httpauth-digest/>.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The document has one ope= n issue related to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 backward
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatibility with RFC25= 43/RFC2069. The backward
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatibility with RFC20= 69 in the HTTP document
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is still
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0under discussion.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I would appreciate any f= eedback on this initial
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 version of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this document.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Great to see this finally happen= !

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A few questions:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01. If you modify the BNF and oth= er things - doesn't
=A0 =A0 =A0 =A0 =A0 =A0 this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0update RFC 3261?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yes, I will add that to the next version= of the draft.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Before Cullen says it:

=A0 =A0 =A0 =A0 =A0 =A0 =A0Do we have to update RFC3261 meaning that everyo= ne is forced to
=A0 =A0 =A0 =A0 =A0 =A0 =A0update to stay
=A0 =A0 =A0 =A0 =A0 =A0 =A0compliant with SIP? Or can we do this as an opti= onal addon?

=A0 =A0 =A0 =A0 =A0 =A0 =A0Moving forward and leaving MD5 behind is desirab= le, but
=A0 =A0 =A0 =A0 maybe not
=A0 =A0 =A0 =A0 =A0 =A0 =A0declaring devices
=A0 =A0 =A0 =A0 =A0 =A0 =A0incompatible with SIP. What is the opinion of th= e SIPcore
=A0 =A0 =A0 =A0 group?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02. You state as an open issue wh= ether we need to keep
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0backwards compatibility
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with 2543/2069. What do you= think, what would be
=A0 =A0 =A0 =A0 =A0 =A0 the effect
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if we don't?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That depends on what we have out there.<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Are there are many deployed systems that= comply to
=A0 =A0 =A0 =A0 =A0 =A0 RFC2543 but not
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC3261?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Do most proxies add the "qop" = parameter today?

=A0 =A0 =A0 =A0 =A0 =A0 =A0Good question. Are proxys really allowed to mess= with the
=A0 =A0 =A0 =A0 =A0 =A0 =A0authentication headers?

=A0 =A0 =A0 =A0 =A0 =A0 =A0If we make this an optional specification, possi= bly with a
=A0 =A0 =A0 =A0 supported
=A0 =A0 =A0 =A0 =A0 =A0 =A0header, like

=A0 =A0 =A0 =A0 =A0 =A0 =A0Supported: strongauth

=A0 =A0 =A0 =A0 =A0 =A0 =A0then we can get rid of the old stuff. And maybe = such a
=A0 =A0 =A0 =A0 header would
=A0 =A0 =A0 =A0 =A0 =A0 =A0help migration.
=A0 =A0 =A0 =A0 =A0 =A0 =A0The server in that case doesn't have to down= grade to md5
=A0 =A0 =A0 =A0 and can
=A0 =A0 =A0 =A0 =A0 =A0 =A0make a decision
=A0 =A0 =A0 =A0 =A0 =A0 =A0on whether it requires this to proceed.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Opinions?

=A0 =A0 =A0 =A0 =A0 =A0 =A0/O



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03. I would like to see a section= that more clearly
=A0 =A0 =A0 =A0 =A0 =A0 defines the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0changes compared
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0with 3261/2543 to make i= t easier for developers to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0understand what they
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0need to change and what = they can keep.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ok.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Cheers,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/O


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rifaat



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0---------- Forwarded mes= sage ----------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From: ** <internet-drafts@ietf.org=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf._= _org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>&g= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Date: Fri, Jan 10, 2014 = at 7:45 PM
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Subject: New Version Not= ification for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-yusef-sipcore-dige= st-__scheme-00.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To: Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:rifaat.ietf@gmail.com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:rifaat.ietf@gmail.com>>__>



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A new version of I-D,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-__scheme-= 00.txt

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has been successfully su= bmitted by Rifaat
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shekh-Yusef and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IETF repository.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Name: =A0 =A0 =A0 =A0 = =A0 draft-yusef-sipcore-digest-__scheme

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Revision: =A0 =A0 =A0 00=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Title: =A0 =A0 =A0 =A0 = =A0The Session Initiation Protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (SIP) Digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Authentication Scheme =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Document date: =A02014-0= 1-10
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Group: =A0 =A0 =A0 =A0 = =A0Individual Submission
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages: =A0 =A0 =A0 =A0 = =A07
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0URL:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.ietf.org/internet-__drafts/draft-yusef-sipcore-__digest-s= cheme-00.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://= www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-schem= e-00.txt>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Status:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://datatrac= ker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://datatrac= ker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Htmlized:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://tools.ietf.or= g/html/__draft-yusef-sipcore-digest-__scheme-00

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://tools.ietf.or= g/html/draft-yusef-sipcore-digest-scheme-00>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This document updat= es the Digest Access
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authentication
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scheme used by
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the Session Initiat= ion Protocol (SIP) to add
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 support for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SHA2 digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithms to repla= ce the MD5 algorithm.





=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please note that it may = take a couple of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 minutes from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0time of submission
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0until the htmlized versi= on and diff are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 available at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tools.ietf.org <http://tools.ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://tools.ietf.org/>.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The IETF Secretariat


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________= _________________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sipcore@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__li= stinfo/sipcore
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/li= stinfo/sipcore>



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________= ________________

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0 =A0 =A0 sipcore@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/s= ipcore
=A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/s= ipcore>





=A0 =A0 =A0 =A0 _________________________________________________
=A0 =A0 =A0 =A0 sipcore mailing list
=A0 =A0 =A0 =A0 sipco= re@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/sipcore
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/sipcore>


=A0 =A0 _________________________________________________

=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/sipcore
=A0 =A0 <https://www.ietf.org/mailman/listinfo/sipcore>



--047d7b33db06898f0404eff78408-- From worley@shell01.TheWorld.com Wed Jan 15 11:52:15 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1611AE13F for ; Wed, 15 Jan 2014 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20sIQLN_2FMY for ; Wed, 15 Jan 2014 11:52:13 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 64DDE1AE128 for ; Wed, 15 Jan 2014 11:52:13 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0FJpcLZ027437; Wed, 15 Jan 2014 14:51:40 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0FJpcWo2871953; Wed, 15 Jan 2014 14:51:38 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0FJpbNX2862598; Wed, 15 Jan 2014 14:51:37 -0500 (EST) Date: Wed, 15 Jan 2014 14:51:37 -0500 (EST) Message-Id: <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> Cc: sipcore@ietf.org Subject: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 19:52:16 -0000 It's great that you are writing this! The draft as it is now written references "[HTTP-DIGEST]" in many places, but does not specify what that *is*. In a sense, this is unavoidable, since the new HTTP-digest RFC isn't out yet. But if one is trying to read *this* draft and figure out its significance, one is blocked by the fact that this draft is written from the point of view of being the glue that connects an unspecified document to SIP. One solution would be to insert a note that tells the reader the current draft name for HTTP-DIGEST, a note that would be removed in the formal publication. Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP servers supporting [HTTP-DIGEST] MUST ensure they are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in [HTTP-DIGEST]. Note, however, that SIP servers MUST NOT accept or request Basic authentication. It's not clear to me what "are backwards compatible with RFC 2069" means, because RFC 2069 deals exclusively with HTTP. And similarly, a SIP server doesn't support [HTTP-DIGEST] per se either. I think you mean to say, "SIP servers conformant to this specification must be backwards compatible with SIP digest authentication as specified in RFC 3261 section 22.4 (which is based on RFC 2069). The procedures for backward compatibility in SIP are the same as those specified for HTTP in [HTTP-DIGEST]." My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to SIP directly; only the modifications of those made by RFC 2543, RFC 3261, and this draft apply to SIP. Therefore, any algorithms that have a dependency on the cnonce (including "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require that the qop directive be sent. Use of the "qop" parameter I think it would read better as "Therefore, any algorithms that require that cnonce be sent (including ...". RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. ... There are now three specifications regarding authentication, RFC 2543, RFC 3261, and "RFC 3261 with the extensions in this document", and you should make clear which spec enables Authentication-Info. The text above seems to say that it is the new draft that enables Authentication-Info, but looking at RFC 3261 clearly shows a specification for its use. ... [HTTP-DIGEST] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in [HTTP-DIGEST] that were not specified in RFC 2069. The connection of remainder of this paragraph to the previous part is unclear to me. It is also unclear what particular "backwards compatibility" is supported "using the qop attribute", as there are now at least two extensions and now two levels of backward compatibility. And given that this seems to be a very general statement about how backwards compatibility (vs. digest auth in 3261) is achieved, it probably should be a separate paragraph. Perhaps this would be clearer to me if I knew off the top of my head the details of the security mechanisms defined in these various documents, and then I would know which document is implied in each reference. But it would be a better exposition if one did not have to be on top of all the details to be able to grasp the overall structure. Also, is "qop" a "directive", a "parameter", or an "attribute"? request-digest = LDQUOT digest-size LHEX RDQUOT digest-size = "32" / "64" This doesn't achieve what you want, since it results in "32a" "62f" being valid request-digest values. The problem is that that in the BNF form "element", "n" must be a literal decimal number. What you intend is request-digest = LDQUOT 32LHEX RDQUOT / LDQUOT 64LHEX RDQUOT But I see in RFC 3261 that response-digest (in Authentication-Info) is syntactically allowed to be variable length: Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Why not allow request-digest to be variable length? request-digest = LDQUOT *LHEX RDQUOT That prevents the need for further revisions if a larger digest is ever defined. Dale From pkyzivat@alum.mit.edu Wed Jan 15 12:24:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF431AE373 for ; Wed, 15 Jan 2014 12:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSXvOentkM30 for ; Wed, 15 Jan 2014 12:24:40 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EAFCF1AE112 for ; Wed, 15 Jan 2014 12:24:39 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id EJp71n0010SCNGk56LQUkD; Wed, 15 Jan 2014 20:24:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id ELQT1n00e3ZTu2S3VLQTPL; Wed, 15 Jan 2014 20:24:28 +0000 Message-ID: <52D6EE7B.2030701@alum.mit.edu> Date: Wed, 15 Jan 2014 15:24:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> In-Reply-To: <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389817468; bh=N+jt1sL4DR36/ZqmEj0DM9ZufcMvDq5gUjjGwN7DBsw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b/9Otb2XmhJ7B2dJdBieUq5dxE+KJ+IV9ynoIkHjbU8TdYPfKIATZ5ppstFvwXmG9 ZJWRKKvfVLZGij8fNdY4Qo5eoQVYVGRMHCLvc03/lXsSCwx3wNLha8/QjOWOFL1OnQ 55tT4BpZdzffvKkJHcSn9bgjuDmoRhPNH/YrPhNRiI7ipUI6Ur8YaoQ8eeM/n0hQRx 0otwh55kp+711CKL1uHrEK7qVOgPModjW82MiBfj2CM4g50EPAZ2TnH7VKKx/Jgg3l SXWKMfcoKvqjBSYHBog7z2+INvHuZcBnf1OqUyAHq7PM2gUqZ6EB00WJYOvS2DHpD8 wUx0XzFw79xjQ== Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 20:24:42 -0000 Regarding the hex stuff: If it is variable length, then it is necessary to specify how it is to be padded. If the algorithm forces it to 32 or 64 bits, does it add pad on the front or the back? Thanks, Paul On 1/15/14 2:51 PM, Dale R. Worley wrote: > It's great that you are writing this! > > The draft as it is now written references "[HTTP-DIGEST]" in many > places, but does not specify what that *is*. In a sense, this is > unavoidable, since the new HTTP-digest RFC isn't out yet. But if one > is trying to read *this* draft and figure out its significance, one is > blocked by the fact that this draft is written from the point of view > of being the glue that connects an unspecified document to SIP. One > solution would be to insert a note that tells the reader the current > draft name for HTTP-DIGEST, a note that would be removed in the formal > publication. > > Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP > servers supporting [HTTP-DIGEST] MUST ensure they are backwards > compatible with RFC 2069. Procedures for this backwards > compatibility are specified in [HTTP-DIGEST]. Note, however, that > SIP servers MUST NOT accept or request Basic authentication. > > It's not clear to me what "are backwards compatible with RFC 2069" > means, because RFC 2069 deals exclusively with HTTP. And similarly, a > SIP server doesn't support [HTTP-DIGEST] per se either. I think you > mean to say, "SIP servers conformant to this specification must be > backwards compatible with SIP digest authentication as specified in > RFC 3261 section 22.4 (which is based on RFC 2069). The procedures > for backward compatibility in SIP are the same as those specified for > HTTP in [HTTP-DIGEST]." > > My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to > SIP directly; only the modifications of those made by RFC 2543, RFC > 3261, and this draft apply to SIP. > > Therefore, any > algorithms that have a dependency on the cnonce (including > "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require > that the qop directive be sent. Use of the "qop" parameter > > I think it would read better as "Therefore, any algorithms that > require that cnonce be sent (including ...". > > RFC 2543 did not allow usage of the Authentication-Info header field > (it effectively used RFC 2069). However, we now allow usage of this > header field, since it provides integrity checks over the bodies and > provides mutual authentication. ... > > There are now three specifications regarding authentication, RFC 2543, > RFC 3261, and "RFC 3261 with the extensions in this document", and you > should make clear which spec enables Authentication-Info. The text > above seems to say that it is the new draft that enables > Authentication-Info, but looking at RFC 3261 clearly shows a > specification for its use. > > ... [HTTP-DIGEST] defines mechanisms for > backwards compatibility using the qop attribute in the request. These > mechanisms MUST be used by a server to determine if the client > supports the new mechanisms in [HTTP-DIGEST] that were not specified > in RFC 2069. > > The connection of remainder of this paragraph to the previous part is > unclear to me. It is also unclear what particular "backwards > compatibility" is supported "using the qop attribute", as there are > now at least two extensions and now two levels of backward > compatibility. > > And given that this seems to be a very general statement about how > backwards compatibility (vs. digest auth in 3261) is achieved, it > probably should be a separate paragraph. > > Perhaps this would be clearer to me if I knew off the top of my head > the details of the security mechanisms defined in these various > documents, and then I would know which document is implied in each > reference. But it would be a better exposition if one did not have to > be on top of all the details to be able to grasp the overall > structure. > > Also, is "qop" a "directive", a "parameter", or an "attribute"? > > request-digest = LDQUOT digest-size LHEX RDQUOT > digest-size = "32" / "64" > > This doesn't achieve what you want, since it results in > "32a" > "62f" > being valid request-digest values. The problem is that that in the > BNF form "element", "n" must be a literal decimal number. What you > intend is > request-digest = LDQUOT 32LHEX RDQUOT > / LDQUOT 64LHEX RDQUOT > But I see in RFC 3261 that response-digest (in Authentication-Info) is > syntactically allowed to be variable length: > Authentication-Info = "Authentication-Info" HCOLON ainfo > *(COMMA ainfo) > ainfo = nextnonce / message-qop > / response-auth / cnonce > / nonce-count > nextnonce = "nextnonce" EQUAL nonce-value > response-auth = "rspauth" EQUAL response-digest > response-digest = LDQUOT *LHEX RDQUOT > Why not allow request-digest to be variable length? > request-digest = LDQUOT *LHEX RDQUOT > That prevents the need for further revisions if a larger digest is > ever defined. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Thu Jan 16 06:31:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814C11AE349 for ; Thu, 16 Jan 2014 06:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXVs4-LuYKwk for ; Thu, 16 Jan 2014 06:31:18 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D71AE0E5 for ; Thu, 16 Jan 2014 06:31:17 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so1189712eaj.40 for ; Thu, 16 Jan 2014 06:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YuYKhh/dgkpilfljndYhdz11OoVLkvDcALw/AFR64t0=; b=EfvvsCoV9p6ZUT2NpjbIq+Ww2tEA2y9mLYaWomd5rFY4yeUXSQNvnBmnbjDfwd9ZZi vJlgfjt/qAFKdRtWzguRpTNtpDpjK+lMle8yru4dyqC4ie46rwdJgw9dLlNUf4Ga6OH5 0i+xroWSJEgzFalTiTQjS0QZxE7niDnQ017ED+M02S6NxYbrte/EisEgCsyp8/wqFYBI 6OKWtO12cKD9esJjyA+lc4qa5tnrvTtWkVQ5meMH+7PGKFpi0ONkJgyvO3Tzi+LH5fnt r2FX/WxPavhlIUBgoUFjWgefqKAV/sMuX+M3G4901c6DvkAejSD4AIUNqHYLLCCgJGab aNgA== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr12682752eew.61.1389882665219; Thu, 16 Jan 2014 06:31:05 -0800 (PST) Received: by 10.14.53.78 with HTTP; Thu, 16 Jan 2014 06:31:05 -0800 (PST) In-Reply-To: <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> Date: Thu, 16 Jan 2014 09:31:05 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c3fb708a3c2604f0174636 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:31:20 -0000 --001a11c3fb708a3c2604f0174636 Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Thanks for your thorough review. I tried to make the draft short and simple and rely on the HTTP draft for more details, but that did not seem to work. I have just submitted a new version of the draft: http://www.ietf.org/id/draft-yusef-sipcore-digest-scheme-01.txt With this version I added more details and described the changes compared to RFC3261, instead of pointing to the HTTP draft. I hope this is a bit more clear than the -00 version. Regards, Rifaat On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley wrote: > It's great that you are writing this! > > The draft as it is now written references "[HTTP-DIGEST]" in many > places, but does not specify what that *is*. In a sense, this is > unavoidable, since the new HTTP-digest RFC isn't out yet. But if one > is trying to read *this* draft and figure out its significance, one is > blocked by the fact that this draft is written from the point of view > of being the glue that connects an unspecified document to SIP. One > solution would be to insert a note that tells the reader the current > draft name for HTTP-DIGEST, a note that would be removed in the formal > publication. > > Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP > servers supporting [HTTP-DIGEST] MUST ensure they are backwards > compatible with RFC 2069. Procedures for this backwards > compatibility are specified in [HTTP-DIGEST]. Note, however, that > SIP servers MUST NOT accept or request Basic authentication. > > It's not clear to me what "are backwards compatible with RFC 2069" > means, because RFC 2069 deals exclusively with HTTP. And similarly, a > SIP server doesn't support [HTTP-DIGEST] per se either. I think you > mean to say, "SIP servers conformant to this specification must be > backwards compatible with SIP digest authentication as specified in > RFC 3261 section 22.4 (which is based on RFC 2069). The procedures > for backward compatibility in SIP are the same as those specified for > HTTP in [HTTP-DIGEST]." > > My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to > SIP directly; only the modifications of those made by RFC 2543, RFC > 3261, and this draft apply to SIP. > > Therefore, any > algorithms that have a dependency on the cnonce (including > "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require > that the qop directive be sent. Use of the "qop" parameter > > I think it would read better as "Therefore, any algorithms that > require that cnonce be sent (including ...". > > RFC 2543 did not allow usage of the Authentication-Info header field > (it effectively used RFC 2069). However, we now allow usage of this > header field, since it provides integrity checks over the bodies and > provides mutual authentication. ... > > There are now three specifications regarding authentication, RFC 2543, > RFC 3261, and "RFC 3261 with the extensions in this document", and you > should make clear which spec enables Authentication-Info. The text > above seems to say that it is the new draft that enables > Authentication-Info, but looking at RFC 3261 clearly shows a > specification for its use. > > ... [HTTP-DIGEST] defines mechanisms for > backwards compatibility using the qop attribute in the request. These > mechanisms MUST be used by a server to determine if the client > supports the new mechanisms in [HTTP-DIGEST] that were not specified > in RFC 2069. > > The connection of remainder of this paragraph to the previous part is > unclear to me. It is also unclear what particular "backwards > compatibility" is supported "using the qop attribute", as there are > now at least two extensions and now two levels of backward > compatibility. > > And given that this seems to be a very general statement about how > backwards compatibility (vs. digest auth in 3261) is achieved, it > probably should be a separate paragraph. > > Perhaps this would be clearer to me if I knew off the top of my head > the details of the security mechanisms defined in these various > documents, and then I would know which document is implied in each > reference. But it would be a better exposition if one did not have to > be on top of all the details to be able to grasp the overall > structure. > > Also, is "qop" a "directive", a "parameter", or an "attribute"? > > request-digest = LDQUOT digest-size LHEX RDQUOT > digest-size = "32" / "64" > > This doesn't achieve what you want, since it results in > "32a" > "62f" > being valid request-digest values. The problem is that that in the > BNF form "element", "n" must be a literal decimal number. What you > intend is > request-digest = LDQUOT 32LHEX RDQUOT > / LDQUOT 64LHEX RDQUOT > But I see in RFC 3261 that response-digest (in Authentication-Info) is > syntactically allowed to be variable length: > Authentication-Info = "Authentication-Info" HCOLON ainfo > *(COMMA ainfo) > ainfo = nextnonce / message-qop > / response-auth / cnonce > / nonce-count > nextnonce = "nextnonce" EQUAL nonce-value > response-auth = "rspauth" EQUAL response-digest > response-digest = LDQUOT *LHEX RDQUOT > Why not allow request-digest to be variable length? > request-digest = LDQUOT *LHEX RDQUOT > That prevents the need for further revisions if a larger digest is > ever defined. > > Dale > --001a11c3fb708a3c2604f0174636 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks for your thorough revie= w.

I tried to make the draft short and simple= and rely on the HTTP draft for more details, but that did not seem to work= .

I have just submitted a new version of the draft:=

With this version I added more details and = described the changes compared to RFC3261, instead of pointing to the HTTP = draft.
I hope this is a bit more clear than the -00 version.<= /div>

Regards,
=A0Rifaat

<= br>


On W= ed, Jan 15, 2014 at 2:51 PM, Dale R. Worley <worley@ariadne.com>= wrote:
It's great that you are writing this!

The draft as it is now written references "[HTTP-DIGEST]" in many=
places, but does not specify what that *is*. =A0In a sense, this is
unavoidable, since the new HTTP-digest RFC isn't out yet. =A0But if one=
is trying to read *this* draft and figure out its significance, one is
blocked by the fact that this draft is written from the point of view
of being the glue that connects an unspecified document to SIP. =A0One
solution would be to insert a note that tells the reader the current
draft name for HTTP-DIGEST, a note that would be removed in the formal
publication.

=A0 =A0Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP =A0 =A0servers supporting [HTTP-DIGEST] MUST ensure they are backwards
=A0 =A0compatible with RFC 2069. =A0Procedures for this backwards
=A0 =A0compatibility are specified in [HTTP-DIGEST]. =A0Note, however, that=
=A0 =A0SIP servers MUST NOT accept or request Basic authentication.

It's not clear to me what "are backwards compatible with RFC 2069&= quot;
means, because RFC 2069 deals exclusively with HTTP. =A0And similarly, a SIP server doesn't support [HTTP-DIGEST] per se either. =A0I think you<= br> mean to say, "SIP servers conformant to this specification must be
backwards compatible with SIP digest authentication as specified in
RFC 3261 section 22.4 (which is based on RFC 2069). =A0The procedures
for backward compatibility in SIP are the same as those specified for
HTTP in [HTTP-DIGEST]."

My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to
SIP directly; only the modifications of those made by RFC 2543, RFC
3261, and this draft apply to SIP.

=A0 =A0 =A0 =A0 =A0 Therefore, any
=A0 =A0 =A0 =A0 =A0 algorithms that have a dependency on the cnonce (includ= ing
=A0 =A0 =A0 =A0 =A0 "MD5-sess", "SHA2-256-sess", and &q= uot;SHA2-512-256-sess") require
=A0 =A0 =A0 =A0 =A0 that the qop directive be sent. =A0Use of the "qop= " parameter

I think it would read better as "Therefore, any algorithms that
require that cnonce be sent (including ...".

=A0 =A0RFC 2543 did not allow usage of the Authentication-Info header field=
=A0 =A0(it effectively used RFC 2069). However, we now allow usage of this<= br> =A0 =A0header field, since it provides integrity checks over the bodies and=
=A0 =A0provides mutual authentication. =A0...

There are now three specifications regarding authentication, RFC 2543,
RFC 3261, and "RFC 3261 with the extensions in this document", an= d you
should make clear which spec enables Authentication-Info. =A0The text
above seems to say that it is the new draft that enables
Authentication-Info, but looking at RFC 3261 clearly shows a
specification for its use.

=A0 =A0... [HTTP-DIGEST] defines mechanisms for
=A0 =A0backwards compatibility using the qop attribute in the request. Thes= e
=A0 =A0mechanisms MUST be used by a server to determine if the client
=A0 =A0supports the new mechanisms in [HTTP-DIGEST] that were not specified=
=A0 =A0in RFC 2069.

The connection of remainder of this paragraph to the previous part is
unclear to me. =A0It is also unclear what particular "backwards
compatibility" is supported "using the qop attribute", as th= ere are
now at least two extensions and now two levels of backward
compatibility.

And given that this seems to be a very general statement about how
backwards compatibility (vs. digest auth in 3261) is achieved, it
probably should be a separate paragraph.

Perhaps this would be clearer to me if I knew off the top of my head
the details of the security mechanisms defined in these various
documents, and then I would know which document is implied in each
reference. =A0But it would be a better exposition if one did not have to be on top of all the details to be able to grasp the overall
structure.

Also, is "qop" a "directive", a "parameter", = or an "attribute"?

=A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT digest-size LHEX RDQUOT
=A0 =A0 =A0 digest-size =A0 =A0 =A0 =3D "32" / "64"

This doesn't achieve what you want, since it results in
=A0 =A0 "32a"
=A0 =A0 "62f"
being valid request-digest values. =A0The problem is that that in the
BNF form "<n>element", "n" must be a literal deci= mal number. =A0What you
intend is
=A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT 32LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0LDQUOT 64LHEX RDQUOT But I see in RFC 3261 that response-digest (in Authentication-Info) is
syntactically allowed to be variable length:
=A0 =A0 Authentication-Info =A0=3D =A0"Authentication-Info" HCOLO= N ainfo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(COMMA ainfo)
=A0 =A0 ainfo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D =A0nextnonce / message-qop=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ response-auth = / cnonce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ nonce-count =A0 =A0 nextnonce =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"nextnonce" EQUAL= nonce-value
=A0 =A0 response-auth =A0 =A0 =A0 =A0=3D =A0"rspauth" EQUAL respo= nse-digest
=A0 =A0 response-digest =A0 =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
Why not allow request-digest to be variable length?
=A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
That prevents the need for further revisions if a larger digest is
ever defined.

Dale

--001a11c3fb708a3c2604f0174636-- From rifaat.ietf@gmail.com Thu Jan 16 06:38:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2841AE33A for ; Thu, 16 Jan 2014 06:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Bsl_mSUPgE for ; Thu, 16 Jan 2014 06:38:18 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 42EBA1AE0E5 for ; Thu, 16 Jan 2014 06:38:18 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so1552828eei.7 for ; Thu, 16 Jan 2014 06:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/4Cr/L9Yw7vTQ3EsLYVswtAuoXhqsEGXW6I61Jd8QQQ=; b=sdnUylGfauSLiIO1mdJMAx7D48Zc4r0zAxJEi37zs7MANEeS/eO9sZEscYtGKa3UVU UG5Yq0Sv46rc/KkKAaGZ4et+gYiR9/aT56Z2o6Wtzva3zTGoEK/3lbnyFWAYnG47dfXT TiZkiVGZ8FFUYXHd/QIPuL01JsO2svOGmaGjW926ADWF2ZM8lyMxG0+O6WLnUyTVx8bE ha694rHeUYYLMCk5j/wImK5z3Cej0AESX+Wd6f6kXcbj0DbIakeR9YOGJLioceluEBRs 6VYTY9wVYEEv0vA/LmtUd0HjoIHQbCtrb7vGOWZVgCNASseG4c6YGua+Q5itGrm0Qb7p yZmw== MIME-Version: 1.0 X-Received: by 10.15.111.6 with SMTP id ci6mr12556522eeb.59.1389883085051; Thu, 16 Jan 2014 06:38:05 -0800 (PST) Received: by 10.14.53.78 with HTTP; Thu, 16 Jan 2014 06:38:05 -0800 (PST) In-Reply-To: <52D6EE7B.2030701@alum.mit.edu> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> <52D6EE7B.2030701@alum.mit.edu> Date: Thu, 16 Jan 2014 09:38:05 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01628384905c2304f0175f5a Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:38:22 -0000 --089e01628384905c2304f0175f5a Content-Type: text/plain; charset=ISO-8859-1 Paul, The digest size depends on the algorithm used; MD5 has an output of 32 hexadecimal characters, and SHA2-256 & SHA2-512/256 have an output of 64 hexadecimal characters. Take a look at section 2.2 for more details: http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-01#section-2.2 Regards, Rifaat On Wed, Jan 15, 2014 at 3:24 PM, Paul Kyzivat wrote: > Regarding the hex stuff: > > If it is variable length, then it is necessary to specify how it is to be > padded. If the algorithm forces it to 32 or 64 bits, does it add pad on the > front or the back? > > Thanks, > Paul > > > On 1/15/14 2:51 PM, Dale R. Worley wrote: > >> It's great that you are writing this! >> >> The draft as it is now written references "[HTTP-DIGEST]" in many >> places, but does not specify what that *is*. In a sense, this is >> unavoidable, since the new HTTP-digest RFC isn't out yet. But if one >> is trying to read *this* draft and figure out its significance, one is >> blocked by the fact that this draft is written from the point of view >> of being the glue that connects an unspecified document to SIP. One >> solution would be to insert a note that tells the reader the current >> draft name for HTTP-DIGEST, a note that would be removed in the formal >> publication. >> >> Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP >> servers supporting [HTTP-DIGEST] MUST ensure they are backwards >> compatible with RFC 2069. Procedures for this backwards >> compatibility are specified in [HTTP-DIGEST]. Note, however, that >> SIP servers MUST NOT accept or request Basic authentication. >> >> It's not clear to me what "are backwards compatible with RFC 2069" >> means, because RFC 2069 deals exclusively with HTTP. And similarly, a >> SIP server doesn't support [HTTP-DIGEST] per se either. I think you >> mean to say, "SIP servers conformant to this specification must be >> backwards compatible with SIP digest authentication as specified in >> RFC 3261 section 22.4 (which is based on RFC 2069). The procedures >> for backward compatibility in SIP are the same as those specified for >> HTTP in [HTTP-DIGEST]." >> >> My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to >> SIP directly; only the modifications of those made by RFC 2543, RFC >> 3261, and this draft apply to SIP. >> >> Therefore, any >> algorithms that have a dependency on the cnonce (including >> "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require >> that the qop directive be sent. Use of the "qop" parameter >> >> I think it would read better as "Therefore, any algorithms that >> require that cnonce be sent (including ...". >> >> RFC 2543 did not allow usage of the Authentication-Info header field >> (it effectively used RFC 2069). However, we now allow usage of this >> header field, since it provides integrity checks over the bodies and >> provides mutual authentication. ... >> >> There are now three specifications regarding authentication, RFC 2543, >> RFC 3261, and "RFC 3261 with the extensions in this document", and you >> should make clear which spec enables Authentication-Info. The text >> above seems to say that it is the new draft that enables >> Authentication-Info, but looking at RFC 3261 clearly shows a >> specification for its use. >> >> ... [HTTP-DIGEST] defines mechanisms for >> backwards compatibility using the qop attribute in the request. These >> mechanisms MUST be used by a server to determine if the client >> supports the new mechanisms in [HTTP-DIGEST] that were not specified >> in RFC 2069. >> >> The connection of remainder of this paragraph to the previous part is >> unclear to me. It is also unclear what particular "backwards >> compatibility" is supported "using the qop attribute", as there are >> now at least two extensions and now two levels of backward >> compatibility. >> >> And given that this seems to be a very general statement about how >> backwards compatibility (vs. digest auth in 3261) is achieved, it >> probably should be a separate paragraph. >> >> Perhaps this would be clearer to me if I knew off the top of my head >> the details of the security mechanisms defined in these various >> documents, and then I would know which document is implied in each >> reference. But it would be a better exposition if one did not have to >> be on top of all the details to be able to grasp the overall >> structure. >> >> Also, is "qop" a "directive", a "parameter", or an "attribute"? >> >> request-digest = LDQUOT digest-size LHEX RDQUOT >> digest-size = "32" / "64" >> >> This doesn't achieve what you want, since it results in >> "32a" >> "62f" >> being valid request-digest values. The problem is that that in the >> BNF form "element", "n" must be a literal decimal number. What you >> intend is >> request-digest = LDQUOT 32LHEX RDQUOT >> / LDQUOT 64LHEX RDQUOT >> But I see in RFC 3261 that response-digest (in Authentication-Info) is >> syntactically allowed to be variable length: >> Authentication-Info = "Authentication-Info" HCOLON ainfo >> *(COMMA ainfo) >> ainfo = nextnonce / message-qop >> / response-auth / cnonce >> / nonce-count >> nextnonce = "nextnonce" EQUAL nonce-value >> response-auth = "rspauth" EQUAL response-digest >> response-digest = LDQUOT *LHEX RDQUOT >> Why not allow request-digest to be variable length? >> request-digest = LDQUOT *LHEX RDQUOT >> That prevents the need for further revisions if a larger digest is >> ever defined. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --089e01628384905c2304f0175f5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,

The digest size depends on the al= gorithm used; MD5 has an output of 32 hexadecimal characters, and SHA2-256 = & SHA2-512/256 have an output of 64 hexadecimal characters.
Take a look at section 2.2 for more details:

Regards,
=A0Rifaat

=


On Wed,= Jan 15, 2014 at 3:24 PM, Paul Kyzivat <pkyzivat@alum.mit.edu><= /span> wrote:
Regarding the hex stuff:

If it is variable length, then it is necessary to specify how it is to be p= added. If the algorithm forces it to 32 or 64 bits, does it add pad on the = front or the back?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 1/15/14 2:51 PM, Dale R. Worley wrote:
It's great that you are writing this!

The draft as it is now written references "[HTTP-DIGEST]" in many=
places, but does not specify what that *is*. =A0In a sense, this is
unavoidable, since the new HTTP-digest RFC isn't out yet. =A0But if one=
is trying to read *this* draft and figure out its significance, one is
blocked by the fact that this draft is written from the point of view
of being the glue that connects an unspecified document to SIP. =A0One
solution would be to insert a note that tells the reader the current
draft name for HTTP-DIGEST, a note that would be removed in the formal
publication.

=A0 =A0 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP<= br> =A0 =A0 servers supporting [HTTP-DIGEST] MUST ensure they are backwards
=A0 =A0 compatible with RFC 2069. =A0Procedures for this backwards
=A0 =A0 compatibility are specified in [HTTP-DIGEST]. =A0Note, however, tha= t
=A0 =A0 SIP servers MUST NOT accept or request Basic authentication.

It's not clear to me what "are backwards compatible with RFC 2069&= quot;
means, because RFC 2069 deals exclusively with HTTP. =A0And similarly, a SIP server doesn't support [HTTP-DIGEST] per se either. =A0I think you<= br> mean to say, "SIP servers conformant to this specification must be
backwards compatible with SIP digest authentication as specified in
RFC 3261 section 22.4 (which is based on RFC 2069). =A0The procedures
for backward compatibility in SIP are the same as those specified for
HTTP in [HTTP-DIGEST]."

My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to
SIP directly; only the modifications of those made by RFC 2543, RFC
3261, and this draft apply to SIP.

=A0 =A0 =A0 =A0 =A0 =A0Therefore, any
=A0 =A0 =A0 =A0 =A0 =A0algorithms that have a dependency on the cnonce (inc= luding
=A0 =A0 =A0 =A0 =A0 =A0"MD5-sess", "SHA2-256-sess", and= "SHA2-512-256-sess") require
=A0 =A0 =A0 =A0 =A0 =A0that the qop directive be sent. =A0Use of the "= qop" parameter

I think it would read better as "Therefore, any algorithms that
require that cnonce be sent (including ...".

=A0 =A0 RFC 2543 did not allow usage of the Authentication-Info header fiel= d
=A0 =A0 (it effectively used RFC 2069). However, we now allow usage of this=
=A0 =A0 header field, since it provides integrity checks over the bodies an= d
=A0 =A0 provides mutual authentication. =A0...

There are now three specifications regarding authentication, RFC 2543,
RFC 3261, and "RFC 3261 with the extensions in this document", an= d you
should make clear which spec enables Authentication-Info. =A0The text
above seems to say that it is the new draft that enables
Authentication-Info, but looking at RFC 3261 clearly shows a
specification for its use.

=A0 =A0 ... [HTTP-DIGEST] defines mechanisms for
=A0 =A0 backwards compatibility using the qop attribute in the request. The= se
=A0 =A0 mechanisms MUST be used by a server to determine if the client
=A0 =A0 supports the new mechanisms in [HTTP-DIGEST] that were not specifie= d
=A0 =A0 in RFC 2069.

The connection of remainder of this paragraph to the previous part is
unclear to me. =A0It is also unclear what particular "backwards
compatibility" is supported "using the qop attribute", as th= ere are
now at least two extensions and now two levels of backward
compatibility.

And given that this seems to be a very general statement about how
backwards compatibility (vs. digest auth in 3261) is achieved, it
probably should be a separate paragraph.

Perhaps this would be clearer to me if I knew off the top of my head
the details of the security mechanisms defined in these various
documents, and then I would know which document is implied in each
reference. =A0But it would be a better exposition if one did not have to be on top of all the details to be able to grasp the overall
structure.

Also, is "qop" a "directive", a "parameter", = or an "attribute"?

=A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT digest-size LHEX RDQUOT<= br> =A0 =A0 =A0 =A0digest-size =A0 =A0 =A0 =3D "32" / "64"<= br>
This doesn't achieve what you want, since it results in
=A0 =A0 =A0"32a"
=A0 =A0 =A0"62f"
being valid request-digest values. =A0The problem is that that in the
BNF form "<n>element", "n" must be a literal deci= mal number. =A0What you
intend is
=A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT 32LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0LDQUOT 64LHEX RDQUO= T
But I see in RFC 3261 that response-digest (in Authentication-Info) is
syntactically allowed to be variable length:
=A0 =A0 =A0Authentication-Info =A0=3D =A0"Authentication-Info" HC= OLON ainfo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(COMMA ainfo)
=A0 =A0 =A0ainfo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D =A0nextnonce / message-= qop
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ response-auth = / cnonce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ nonce-count =A0 =A0 =A0nextnonce =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"nextnonce" EQ= UAL nonce-value
=A0 =A0 =A0response-auth =A0 =A0 =A0 =A0=3D =A0"rspauth" EQUAL re= sponse-digest
=A0 =A0 =A0response-digest =A0 =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
Why not allow request-digest to be variable length?
=A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
That prevents the need for further revisions if a larger digest is
ever defined.

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--089e01628384905c2304f0175f5a-- From worley@shell01.TheWorld.com Thu Jan 16 12:16:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995771AC499 for ; Thu, 16 Jan 2014 12:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqZZ0P0iSrog for ; Thu, 16 Jan 2014 12:16:15 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E72F61A1F6F for ; Thu, 16 Jan 2014 12:16:14 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0GKFrsF005076; Thu, 16 Jan 2014 15:15:55 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0GKFoXc2945387; Thu, 16 Jan 2014 15:15:51 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0GKFo5u2943993; Thu, 16 Jan 2014 15:15:50 -0500 (EST) Date: Thu, 16 Jan 2014 15:15:50 -0500 (EST) Message-Id: <201401162015.s0GKFo5u2943993@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <52D6EE7B.2030701@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> <52D6EE7B.2030701@alum.mit.edu> Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:16:16 -0000 > From: Paul Kyzivat > > Regarding the hex stuff: > > If it is variable length, then it is necessary to specify how it is > to be padded. If the algorithm forces it to 32 or 64 [hex digits], > does it add pad on the front or the back? I wouldn't expect it to be padded at all: The hash outputs a certain number of hex digits, and the request-digest has to match, including the length, or auth fails. Of course, that the length must match isn't stated anywhere. But we run into that problem even if the syntax only allows the choice between 32 or 64 hex digits. I think we're already running into that problem with Authentication-Info... Dale From pkyzivat@alum.mit.edu Thu Jan 16 15:00:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287E81ACC89 for ; Thu, 16 Jan 2014 15:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgxr-m-BV7yF for ; Thu, 16 Jan 2014 15:00:57 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB31A1F65 for ; Thu, 16 Jan 2014 15:00:56 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta14.westchester.pa.mail.comcast.net with comcast id Emxj1n0050EZKEL5En0kBH; Thu, 16 Jan 2014 23:00:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id En0k1n00L3ZTu2S3Mn0kH5; Thu, 16 Jan 2014 23:00:44 +0000 Message-ID: <52D8649C.10308@alum.mit.edu> Date: Thu, 16 Jan 2014 18:00:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389913244; bh=jrBjjQAA7pOwGMXkov4+l9Yx8q+9dMVlRVDLXdiG38I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QMrW8R5GMxHjDKiPAmK3L27kE2ukg4TymyYy6ZYou3slbxQa22fyPuF/N1TBKyUMu v16N/4IINZM8wBiwxpmTe8GZDnZ90vAh0pGFYrR+vltsq/SDbXH1tVn4Voa24Tl7nr uSZK2Xsmf3CxbBNMvOh43gaCiz88L8qWtvISFcGG/cId9Fr3VZQU9J0/hWi7qr3BA1 1CqY1859VicSQd4QES1/zbZrJidz6uakaWXnIjTAOlGfbH1Jq2oLtArfxK/WnS24Pb BpCXCxjp/a38QajsedHnNIZMuvEOvflfuYHF6lKZl6c35E0NKmE7XbX8G4epIvH2Kn 1uT9D5EoH+EoA== Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 23:00:59 -0000 Rifaat, The new version is a definite improvement. Now I have more to comment on. :-) Section 2.1 defines a preference list. How would this be affected by the registration of additional algorithms in the future? ISTM that if there is reason to have a "standard" preference list, then it ought to be part of the registry. (Or perhaps this document should simply state that the the challenger should list the algorithms it supports in order of strength of the algorithm. Similarly, section 2.2 specifies the size of the digest per algorithm, for the currently defined algorithms. Again, shouldn't this be part of the registry, or perhaps there should just be a statement that the registry references a document that describes the algorithm, and the size of the digest must be specified as part of the algorithm description. In section 2.4, it might be helpful to state that if the UAC doesn't support any of the algorithms in the response that it should abandon attempts to send this request. In section 2.5: You give a separate definition of H(entity-body) for SHA2-256 and SHA2-512-256. But what if some other algorithm from the registry is used? ISTM that what is needed is a general mechanism, parameterized by the selected algorithm. Also, I think specifying this as informal deltas to 3261 is going to cause a great deal of trouble. I think it would be better to restate most or all of section 22.4 with the needed changes applied. In section 3: If there is to be a registry, then I think enumerating the values from the registry in the ABNF is counter-productive. It will simply lead to confusion about what needs to be done to add another algorithm. I suggest something along the lines of: algorithm = "algorithm" EQUAL ( / token ) (And I'm debating whether 'token' ought to be there. I think not.) There is then a requirement that new values added to the registry must be compatible with the syntax of 'token'. That will need to go into [HTTP-DIGEST] that specifies the registry and requirements for adding to it. Thanks, Paul > Thanks for your thorough review. > > I tried to make the draft short and simple and rely on the HTTP draft > for more details, but that did not seem to work. > > I have just submitted a new version of the draft: > http://www.ietf.org/id/draft-yusef-sipcore-digest-scheme-01.txt > > With this version I added more details and described the changes > compared to RFC3261, instead of pointing to the HTTP draft. > I hope this is a bit more clear than the -00 version. > > Regards, > Rifaat > > > > > On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley > wrote: > > It's great that you are writing this! > > The draft as it is now written references "[HTTP-DIGEST]" in many > places, but does not specify what that *is*. In a sense, this is > unavoidable, since the new HTTP-digest RFC isn't out yet. But if one > is trying to read *this* draft and figure out its significance, one is > blocked by the fact that this draft is written from the point of view > of being the glue that connects an unspecified document to SIP. One > solution would be to insert a note that tells the reader the current > draft name for HTTP-DIGEST, a note that would be removed in the formal > publication. > > Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP > servers supporting [HTTP-DIGEST] MUST ensure they are backwards > compatible with RFC 2069. Procedures for this backwards > compatibility are specified in [HTTP-DIGEST]. Note, however, that > SIP servers MUST NOT accept or request Basic authentication. > > It's not clear to me what "are backwards compatible with RFC 2069" > means, because RFC 2069 deals exclusively with HTTP. And similarly, a > SIP server doesn't support [HTTP-DIGEST] per se either. I think you > mean to say, "SIP servers conformant to this specification must be > backwards compatible with SIP digest authentication as specified in > RFC 3261 section 22.4 (which is based on RFC 2069). The procedures > for backward compatibility in SIP are the same as those specified for > HTTP in [HTTP-DIGEST]." > > My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to > SIP directly; only the modifications of those made by RFC 2543, RFC > 3261, and this draft apply to SIP. > > Therefore, any > algorithms that have a dependency on the cnonce (including > "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require > that the qop directive be sent. Use of the "qop" parameter > > I think it would read better as "Therefore, any algorithms that > require that cnonce be sent (including ...". > > RFC 2543 did not allow usage of the Authentication-Info header field > (it effectively used RFC 2069). However, we now allow usage of this > header field, since it provides integrity checks over the bodies and > provides mutual authentication. ... > > There are now three specifications regarding authentication, RFC 2543, > RFC 3261, and "RFC 3261 with the extensions in this document", and you > should make clear which spec enables Authentication-Info. The text > above seems to say that it is the new draft that enables > Authentication-Info, but looking at RFC 3261 clearly shows a > specification for its use. > > ... [HTTP-DIGEST] defines mechanisms for > backwards compatibility using the qop attribute in the request. > These > mechanisms MUST be used by a server to determine if the client > supports the new mechanisms in [HTTP-DIGEST] that were not specified > in RFC 2069. > > The connection of remainder of this paragraph to the previous part is > unclear to me. It is also unclear what particular "backwards > compatibility" is supported "using the qop attribute", as there are > now at least two extensions and now two levels of backward > compatibility. > > And given that this seems to be a very general statement about how > backwards compatibility (vs. digest auth in 3261) is achieved, it > probably should be a separate paragraph. > > Perhaps this would be clearer to me if I knew off the top of my head > the details of the security mechanisms defined in these various > documents, and then I would know which document is implied in each > reference. But it would be a better exposition if one did not have to > be on top of all the details to be able to grasp the overall > structure. > > Also, is "qop" a "directive", a "parameter", or an "attribute"? > > request-digest = LDQUOT digest-size LHEX RDQUOT > digest-size = "32" / "64" > > This doesn't achieve what you want, since it results in > "32a" > "62f" > being valid request-digest values. The problem is that that in the > BNF form "element", "n" must be a literal decimal number. What you > intend is > request-digest = LDQUOT 32LHEX RDQUOT > / LDQUOT 64LHEX RDQUOT > But I see in RFC 3261 that response-digest (in Authentication-Info) is > syntactically allowed to be variable length: > Authentication-Info = "Authentication-Info" HCOLON ainfo > *(COMMA ainfo) > ainfo = nextnonce / message-qop > / response-auth / cnonce > / nonce-count > nextnonce = "nextnonce" EQUAL nonce-value > response-auth = "rspauth" EQUAL response-digest > response-digest = LDQUOT *LHEX RDQUOT > Why not allow request-digest to be variable length? > request-digest = LDQUOT *LHEX RDQUOT > That prevents the need for further revisions if a larger digest is > ever defined. > > Dale > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Fri Jan 17 18:37:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE03F1AD791 for ; Fri, 17 Jan 2014 18:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVjMheqtGjG2 for ; Fri, 17 Jan 2014 18:37:13 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 504251AD6C1 for ; Fri, 17 Jan 2014 18:37:13 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so2372303eei.21 for ; Fri, 17 Jan 2014 18:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mOrk351st+cD5r1yRzbw9XdZ8aV2zfxH8Ee7vkh76HE=; b=VM3uqkfdKOYQpqPtNTR7rv5YrvTF80X5sNc/JmLHAcEM7U5jAFHzTSmoFD+iFUXzLK VbuXbggDGA5OQ91+FLNbfY67T9RNpoN4gLFwo3D4NCtf2RGTeAOzsXU/KnYtNXYHa6qE maPPKQ7VV44kzxiZmMhjAufJyi+rTneTdG1t1Q+lLUde++1qb8EN24lh5cZklnRNRs7X uTVjkN+iarbkcmUZz5/ap5q3fL9LOxCcSDAcOl60dRIp3NS1IlJ2/cGEkku24qdogE3w UyVg+gODWldrhIx36VjgdTBZt5CTZteEzk0tqMTNyetFjJixEiw44feNBmmXMePcrhk4 gg1Q== MIME-Version: 1.0 X-Received: by 10.14.175.131 with SMTP id z3mr540629eel.65.1390012620148; Fri, 17 Jan 2014 18:37:00 -0800 (PST) Received: by 10.14.53.78 with HTTP; Fri, 17 Jan 2014 18:37:00 -0800 (PST) Date: Fri, 17 Jan 2014 21:37:00 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b6221487512d104f035888e Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 02:37:17 -0000 --047d7b6221487512d104f035888e Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, Thanks for the thorough review. I have addressed most of your comments in version -02: http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-02 See more inline... Regards, Rifaat On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyzivat wrote: > Rifaat, > > The new version is a definite improvement. Now I have more to comment on. > :-) > > Section 2.1 defines a preference list. How would this be affected by the > registration of additional algorithms in the future? ISTM that if there is > reason to have a "standard" preference list, then it ought to be part of > the registry. (Or perhaps this document should simply state that the the > challenger should list the algorithms it supports in order of strength of > the algorithm. > > I changed the text to align with what you have between the parenthesis. Similarly, section 2.2 specifies the size of the digest per algorithm, for > the currently defined algorithms. Again, shouldn't this be part of the > registry, or perhaps there should just be a statement that the registry > references a document that describes the algorithm, and the size of the > digest must be specified as part of the algorithm description. > > I will changes the registry in the HTTP draft to add output size and preference, and see how far we can go with that. In section 2.4, it might be helpful to state that if the UAC doesn't > support any of the algorithms in the response that it should abandon > attempts to send this request. > > Done > In section 2.5: > > You give a separate definition of H(entity-body) for SHA2-256 and > SHA2-512-256. But what if some other algorithm from the registry is used? > ISTM that what is needed is a general mechanism, parameterized by the > selected algorithm. > > I am not clear on this. All I provided was hashes of different algorithms for empty string; how would you parameterize that? > Also, I think specifying this as informal deltas to 3261 is going to cause > a great deal of trouble. I think it would be better to restate most or all > of section 22.4 with the needed changes applied. > > Done. > In section 3: > > If there is to be a registry, then I think enumerating the values from the > registry in the ABNF is counter-productive. It will simply lead to > confusion about what needs to be done to add another algorithm. I suggest > something along the lines of: > > algorithm = "algorithm" EQUAL ( > > / token ) > > (And I'm debating whether 'token' ought to be there. I think not.) > > There is then a requirement that new values added to the registry must be > compatible with the syntax of 'token'. That will need to go into > [HTTP-DIGEST] that specifies the registry and requirements for adding to it. > > Thanks, > Paul > > Thanks for your thorough review. >> >> I tried to make the draft short and simple and rely on the HTTP draft >> for more details, but that did not seem to work. >> >> I have just submitted a new version of the draft: >> http://www.ietf.org/id/draft-yusef-sipcore-digest-scheme-01.txt >> >> With this version I added more details and described the changes >> compared to RFC3261, instead of pointing to the HTTP draft. >> I hope this is a bit more clear than the -00 version. >> >> Regards, >> Rifaat >> >> >> >> >> On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley > > wrote: >> >> It's great that you are writing this! >> >> The draft as it is now written references "[HTTP-DIGEST]" in many >> places, but does not specify what that *is*. In a sense, this is >> unavoidable, since the new HTTP-digest RFC isn't out yet. But if one >> is trying to read *this* draft and figure out its significance, one is >> blocked by the fact that this draft is written from the point of view >> of being the glue that connects an unspecified document to SIP. One >> solution would be to insert a note that tells the reader the current >> draft name for HTTP-DIGEST, a note that would be removed in the formal >> publication. >> >> Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP >> servers supporting [HTTP-DIGEST] MUST ensure they are backwards >> compatible with RFC 2069. Procedures for this backwards >> compatibility are specified in [HTTP-DIGEST]. Note, however, that >> SIP servers MUST NOT accept or request Basic authentication. >> >> It's not clear to me what "are backwards compatible with RFC 2069" >> means, because RFC 2069 deals exclusively with HTTP. And similarly, a >> SIP server doesn't support [HTTP-DIGEST] per se either. I think you >> mean to say, "SIP servers conformant to this specification must be >> backwards compatible with SIP digest authentication as specified in >> RFC 3261 section 22.4 (which is based on RFC 2069). The procedures >> for backward compatibility in SIP are the same as those specified for >> HTTP in [HTTP-DIGEST]." >> >> My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to >> SIP directly; only the modifications of those made by RFC 2543, RFC >> 3261, and this draft apply to SIP. >> >> Therefore, any >> algorithms that have a dependency on the cnonce (including >> "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") >> require >> that the qop directive be sent. Use of the "qop" parameter >> >> I think it would read better as "Therefore, any algorithms that >> require that cnonce be sent (including ...". >> >> RFC 2543 did not allow usage of the Authentication-Info header >> field >> (it effectively used RFC 2069). However, we now allow usage of >> this >> header field, since it provides integrity checks over the bodies >> and >> provides mutual authentication. ... >> >> There are now three specifications regarding authentication, RFC 2543, >> RFC 3261, and "RFC 3261 with the extensions in this document", and you >> should make clear which spec enables Authentication-Info. The text >> above seems to say that it is the new draft that enables >> Authentication-Info, but looking at RFC 3261 clearly shows a >> specification for its use. >> >> ... [HTTP-DIGEST] defines mechanisms for >> backwards compatibility using the qop attribute in the request. >> These >> mechanisms MUST be used by a server to determine if the client >> supports the new mechanisms in [HTTP-DIGEST] that were not >> specified >> in RFC 2069. >> >> The connection of remainder of this paragraph to the previous part is >> unclear to me. It is also unclear what particular "backwards >> compatibility" is supported "using the qop attribute", as there are >> now at least two extensions and now two levels of backward >> compatibility. >> >> And given that this seems to be a very general statement about how >> backwards compatibility (vs. digest auth in 3261) is achieved, it >> probably should be a separate paragraph. >> >> Perhaps this would be clearer to me if I knew off the top of my head >> the details of the security mechanisms defined in these various >> documents, and then I would know which document is implied in each >> reference. But it would be a better exposition if one did not have to >> be on top of all the details to be able to grasp the overall >> structure. >> >> Also, is "qop" a "directive", a "parameter", or an "attribute"? >> >> request-digest = LDQUOT digest-size LHEX RDQUOT >> digest-size = "32" / "64" >> >> This doesn't achieve what you want, since it results in >> "32a" >> "62f" >> being valid request-digest values. The problem is that that in the >> BNF form "element", "n" must be a literal decimal number. What you >> intend is >> request-digest = LDQUOT 32LHEX RDQUOT >> / LDQUOT 64LHEX RDQUOT >> But I see in RFC 3261 that response-digest (in Authentication-Info) is >> syntactically allowed to be variable length: >> Authentication-Info = "Authentication-Info" HCOLON ainfo >> *(COMMA ainfo) >> ainfo = nextnonce / message-qop >> / response-auth / cnonce >> / nonce-count >> nextnonce = "nextnonce" EQUAL nonce-value >> response-auth = "rspauth" EQUAL response-digest >> response-digest = LDQUOT *LHEX RDQUOT >> Why not allow request-digest to be variable length? >> request-digest = LDQUOT *LHEX RDQUOT >> That prevents the need for further revisions if a larger digest is >> ever defined. >> >> Dale >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --047d7b6221487512d104f035888e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for the thorough review= .

I have addressed most of your comments in versio= n -02:

See more inline...

Regards,
=A0Rifaat


<= br>
On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyz= ivat <pkyzivat@alum.mit.edu> wrote:
Rifaat,

The new version is a definite improvement. Now I have more to comment on. := -)

Section 2.1 defines a preference list. How would this be affected by the re= gistration of additional algorithms in the future? ISTM that if there is re= ason to have a "standard" preference list, then it ought to be pa= rt of the registry. (Or perhaps this document should simply state that the = the challenger should list the algorithms it supports in order of strength = of the algorithm.

I changed the text to align with what you have betwee= n the parenthesis.
=A0

Similarly, section 2.2 specifies the size of the digest per algorithm, for = the currently defined algorithms. Again, shouldn't this be part of the = registry, or perhaps there should just be a statement that the registry ref= erences a document that describes the algorithm, and the size of the digest= must be specified as part of the algorithm description.

I will changes the registry in the HTTP draft to add = output size and preference, and see how far we can go with that.
<= div>

In section 2.4, it might be helpful to state that if the UAC doesn't su= pport any of the algorithms in the response that it should abandon attempts= to send this request.

Done

=A0
In section 2.5:

You give a separate definition of H(entity-body) for SHA2-256 and SHA2-512-= 256. But what if some other algorithm from the registry is used? ISTM that = what is needed is a general mechanism, parameterized by the selected algori= thm.

I am not clear on this. All I provided was hashes of = different algorithms for empty string; how would you parameterize that?

=A0
Also, I think specifying this as informal deltas to 3261 is going to cause = a great deal of trouble. I think it would be better to restate most or all = of section 22.4 with the needed changes applied.

Done.

=A0
In section 3:

If there is to be a registry, then I think enumerating the values from the = registry in the ABNF is counter-productive. It will simply lead to confusio= n about what needs to be done to add another algorithm. I suggest something= along the lines of:

=A0 =A0 =A0 algorithm =3D =A0"algorithm" EQUAL (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<digest-alg-name-from-IANA-registry>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ token )

(And I'm debating whether 'token' ought to be there. I think no= t.)

There is then a requirement that new values added to the registry must be c= ompatible with the syntax of 'token'. That will need to go into [HT= TP-DIGEST] that specifies the registry and requirements for adding to it.
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Thanks for your thorough review.

I tried to make the draft short and simple and rely on the HTTP draft
for more details, but that did not seem to work.

I have just submitted a new version of the draft:
http://www.ietf.org/id/draft-yusef-sipcore-digest= -scheme-01.txt

With this version I added more details and described the changes
compared to RFC3261, instead of pointing to the HTTP draft.
I hope this is a bit more clear than the -00 version.

Regards,
=A0 Rifaat




On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley <worley@ariadne.com
<mailto:worley@a= riadne.com>> wrote:

=A0 =A0 It's great that you are writing this!

=A0 =A0 The draft as it is now written references "[HTTP-DIGEST]"= in many
=A0 =A0 places, but does not specify what that *is*. =A0In a sense, this is=
=A0 =A0 unavoidable, since the new HTTP-digest RFC isn't out yet. =A0Bu= t if one
=A0 =A0 is trying to read *this* draft and figure out its significance, one= is
=A0 =A0 blocked by the fact that this draft is written from the point of vi= ew
=A0 =A0 of being the glue that connects an unspecified document to SIP. =A0= One
=A0 =A0 solution would be to insert a note that tells the reader the curren= t
=A0 =A0 draft name for HTTP-DIGEST, a note that would be removed in the for= mal
=A0 =A0 publication.

=A0 =A0 =A0 =A0 Since RFC 2543 is based on HTTP Digest as defined in RFC 20= 69, SIP
=A0 =A0 =A0 =A0 servers supporting [HTTP-DIGEST] MUST ensure they are backw= ards
=A0 =A0 =A0 =A0 compatible with RFC 2069. =A0Procedures for this backwards<= br> =A0 =A0 =A0 =A0 compatibility are specified in [HTTP-DIGEST]. =A0Note, howe= ver, that
=A0 =A0 =A0 =A0 SIP servers MUST NOT accept or request Basic authentication= .

=A0 =A0 It's not clear to me what "are backwards compatible with R= FC 2069"
=A0 =A0 means, because RFC 2069 deals exclusively with HTTP. =A0And similar= ly, a
=A0 =A0 SIP server doesn't support [HTTP-DIGEST] per se either. =A0I th= ink you
=A0 =A0 mean to say, "SIP servers conformant to this specification mus= t be
=A0 =A0 backwards compatible with SIP digest authentication as specified in=
=A0 =A0 RFC 3261 section 22.4 (which is based on RFC 2069). =A0The procedur= es
=A0 =A0 for backward compatibility in SIP are the same as those specified f= or
=A0 =A0 HTTP in [HTTP-DIGEST]."

=A0 =A0 My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies t= o
=A0 =A0 SIP directly; only the modifications of those made by RFC 2543, RFC=
=A0 =A0 3261, and this draft apply to SIP.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Therefore, any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0algorithms that have a dependency on the cno= nce (including
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"MD5-sess", "SHA2-256-sess&qu= ot;, and "SHA2-512-256-sess") require
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the qop directive be sent. =A0Use of th= e "qop" parameter

=A0 =A0 I think it would read better as "Therefore, any algorithms tha= t
=A0 =A0 require that cnonce be sent (including ...".

=A0 =A0 =A0 =A0 RFC 2543 did not allow usage of the Authentication-Info hea= der field
=A0 =A0 =A0 =A0 (it effectively used RFC 2069). However, we now allow usage= of this
=A0 =A0 =A0 =A0 header field, since it provides integrity checks over the b= odies and
=A0 =A0 =A0 =A0 provides mutual authentication. =A0...

=A0 =A0 There are now three specifications regarding authentication, RFC 25= 43,
=A0 =A0 RFC 3261, and "RFC 3261 with the extensions in this document&q= uot;, and you
=A0 =A0 should make clear which spec enables Authentication-Info. =A0The te= xt
=A0 =A0 above seems to say that it is the new draft that enables
=A0 =A0 Authentication-Info, but looking at RFC 3261 clearly shows a
=A0 =A0 specification for its use.

=A0 =A0 =A0 =A0 ... [HTTP-DIGEST] defines mechanisms for
=A0 =A0 =A0 =A0 backwards compatibility using the qop attribute in the requ= est.
=A0 =A0 These
=A0 =A0 =A0 =A0 mechanisms MUST be used by a server to determine if the cli= ent
=A0 =A0 =A0 =A0 supports the new mechanisms in [HTTP-DIGEST] that were not = specified
=A0 =A0 =A0 =A0 in RFC 2069.

=A0 =A0 The connection of remainder of this paragraph to the previous part = is
=A0 =A0 unclear to me. =A0It is also unclear what particular "backward= s
=A0 =A0 compatibility" is supported "using the qop attribute"= ;, as there are
=A0 =A0 now at least two extensions and now two levels of backward
=A0 =A0 compatibility.

=A0 =A0 And given that this seems to be a very general statement about how<= br> =A0 =A0 backwards compatibility (vs. digest auth in 3261) is achieved, it =A0 =A0 probably should be a separate paragraph.

=A0 =A0 Perhaps this would be clearer to me if I knew off the top of my hea= d
=A0 =A0 the details of the security mechanisms defined in these various
=A0 =A0 documents, and then I would know which document is implied in each<= br> =A0 =A0 reference. =A0But it would be a better exposition if one did not ha= ve to
=A0 =A0 be on top of all the details to be able to grasp the overall
=A0 =A0 structure.

=A0 =A0 Also, is "qop" a "directive", a "parameter= ", or an "attribute"?

=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT digest-size LHEX= RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0digest-size =A0 =A0 =A0 =3D "32" / "6= 4"

=A0 =A0 This doesn't achieve what you want, since it results in
=A0 =A0 =A0 =A0 =A0"32a"
=A0 =A0 =A0 =A0 =A0"62f"
=A0 =A0 being valid request-digest values. =A0The problem is that that in t= he
=A0 =A0 BNF form "<n>element", "n" must be a lite= ral decimal number. =A0What you
=A0 =A0 intend is
=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT 32LHEX RDQUOT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0LDQUOT 64LH= EX RDQUOT
=A0 =A0 But I see in RFC 3261 that response-digest (in Authentication-Info)= is
=A0 =A0 syntactically allowed to be variable length:
=A0 =A0 =A0 =A0 =A0Authentication-Info =A0=3D =A0"Authentication-Info&= quot; HCOLON ainfo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*(COMMA = ainfo)
=A0 =A0 =A0 =A0 =A0ainfo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D =A0nextnonce / = message-qop
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / respo= nse-auth / cnonce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / nonce= -count
=A0 =A0 =A0 =A0 =A0nextnonce =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"nextnonce&= quot; EQUAL nonce-value
=A0 =A0 =A0 =A0 =A0response-auth =A0 =A0 =A0 =A0=3D =A0"rspauth" = EQUAL response-digest
=A0 =A0 =A0 =A0 =A0response-digest =A0 =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT =A0 =A0 Why not allow request-digest to be variable length?
=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
=A0 =A0 That prevents the need for further revisions if a larger digest is<= br> =A0 =A0 ever defined.

=A0 =A0 Dale




_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--047d7b6221487512d104f035888e-- From rifaat.ietf@gmail.com Sat Jan 18 03:01:31 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046CF1ADED5 for ; Sat, 18 Jan 2014 03:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-ngbLlv7w4n for ; Sat, 18 Jan 2014 03:01:28 -0800 (PST) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C54251ADEBF for ; Sat, 18 Jan 2014 03:01:27 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so2530678eei.7 for ; Sat, 18 Jan 2014 03:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=darf4rdutlPslwHTz90qfhP/x+h+/fG3EQgbU1QgWkw=; b=GeZCrHL3nYzJUhFJmjmURNvwVS/JJKAU2wN5TxZr/aNiZjWExeBc8oylwSBEL13XeR 4O50AtxshoL7khgBd2X00swqCgowo0pFnunzV7GilV2RtEwBQeJfAw3TRelyS48ATYtM vS5fKPpaNYbFoqWmicQ8nbR8Gfs1Z0ofR4MnNZUNLMAEl7hceQpZ1zMhlIvapyTtTiHe SKgGKiLxya2vQ6RpaZQf4iBg6c7Dy6sjmwzDHAjLScq14O+3az8Vb6dY/0Z0AsD4Gc6e KrT9chFeULUjQd0xeSLRk1ZgPgkYfEFqE/lE2MiLq0Z3xUOdDw9PkxucXr9KvphKTIxY YOiA== MIME-Version: 1.0 X-Received: by 10.15.111.6 with SMTP id ci6mr7434749eeb.59.1390042874555; Sat, 18 Jan 2014 03:01:14 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 03:01:14 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Jan 2014 06:01:14 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01628384c2afca04f03c9334 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 11:01:31 -0000 --089e01628384c2afca04f03c9334 Content-Type: text/plain; charset=ISO-8859-1 I forgot to mention that I added a new section about forking (section 2.5). Regards, Rifaat On Fri, Jan 17, 2014 at 9:37 PM, Rifaat Shekh-Yusef wrote: > Hi Paul, > > Thanks for the thorough review. > > I have addressed most of your comments in version -02: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-02 > > See more inline... > > Regards, > Rifaat > > > > > On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyzivat wrote: > >> Rifaat, >> >> The new version is a definite improvement. Now I have more to comment on. >> :-) >> >> Section 2.1 defines a preference list. How would this be affected by the >> registration of additional algorithms in the future? ISTM that if there is >> reason to have a "standard" preference list, then it ought to be part of >> the registry. (Or perhaps this document should simply state that the the >> challenger should list the algorithms it supports in order of strength of >> the algorithm. >> >> I changed the text to align with what you have between the parenthesis. > > > Similarly, section 2.2 specifies the size of the digest per algorithm, for >> the currently defined algorithms. Again, shouldn't this be part of the >> registry, or perhaps there should just be a statement that the registry >> references a document that describes the algorithm, and the size of the >> digest must be specified as part of the algorithm description. >> >> I will changes the registry in the HTTP draft to add output size and > preference, and see how far we can go with that. > > > In section 2.4, it might be helpful to state that if the UAC doesn't >> support any of the algorithms in the response that it should abandon >> attempts to send this request. >> >> Done > > > >> In section 2.5: >> >> You give a separate definition of H(entity-body) for SHA2-256 and >> SHA2-512-256. But what if some other algorithm from the registry is used? >> ISTM that what is needed is a general mechanism, parameterized by the >> selected algorithm. >> >> I am not clear on this. All I provided was hashes of different algorithms > for empty string; how would you parameterize that? > > > >> Also, I think specifying this as informal deltas to 3261 is going to >> cause a great deal of trouble. I think it would be better to restate most >> or all of section 22.4 with the needed changes applied. >> >> Done. > > > >> In section 3: >> >> If there is to be a registry, then I think enumerating the values from >> the registry in the ABNF is counter-productive. It will simply lead to >> confusion about what needs to be done to add another algorithm. I suggest >> something along the lines of: >> >> algorithm = "algorithm" EQUAL ( >> >> / token ) >> >> (And I'm debating whether 'token' ought to be there. I think not.) >> >> There is then a requirement that new values added to the registry must be >> compatible with the syntax of 'token'. That will need to go into >> [HTTP-DIGEST] that specifies the registry and requirements for adding to it. >> >> Thanks, >> Paul >> >> Thanks for your thorough review. >>> >>> I tried to make the draft short and simple and rely on the HTTP draft >>> for more details, but that did not seem to work. >>> >>> I have just submitted a new version of the draft: >>> http://www.ietf.org/id/draft-yusef-sipcore-digest-scheme-01.txt >>> >>> With this version I added more details and described the changes >>> compared to RFC3261, instead of pointing to the HTTP draft. >>> I hope this is a bit more clear than the -00 version. >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley >> > wrote: >>> >>> It's great that you are writing this! >>> >>> The draft as it is now written references "[HTTP-DIGEST]" in many >>> places, but does not specify what that *is*. In a sense, this is >>> unavoidable, since the new HTTP-digest RFC isn't out yet. But if one >>> is trying to read *this* draft and figure out its significance, one >>> is >>> blocked by the fact that this draft is written from the point of view >>> of being the glue that connects an unspecified document to SIP. One >>> solution would be to insert a note that tells the reader the current >>> draft name for HTTP-DIGEST, a note that would be removed in the >>> formal >>> publication. >>> >>> Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, >>> SIP >>> servers supporting [HTTP-DIGEST] MUST ensure they are backwards >>> compatible with RFC 2069. Procedures for this backwards >>> compatibility are specified in [HTTP-DIGEST]. Note, however, >>> that >>> SIP servers MUST NOT accept or request Basic authentication. >>> >>> It's not clear to me what "are backwards compatible with RFC 2069" >>> means, because RFC 2069 deals exclusively with HTTP. And similarly, >>> a >>> SIP server doesn't support [HTTP-DIGEST] per se either. I think you >>> mean to say, "SIP servers conformant to this specification must be >>> backwards compatible with SIP digest authentication as specified in >>> RFC 3261 section 22.4 (which is based on RFC 2069). The procedures >>> for backward compatibility in SIP are the same as those specified for >>> HTTP in [HTTP-DIGEST]." >>> >>> My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to >>> SIP directly; only the modifications of those made by RFC 2543, RFC >>> 3261, and this draft apply to SIP. >>> >>> Therefore, any >>> algorithms that have a dependency on the cnonce (including >>> "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") >>> require >>> that the qop directive be sent. Use of the "qop" >>> parameter >>> >>> I think it would read better as "Therefore, any algorithms that >>> require that cnonce be sent (including ...". >>> >>> RFC 2543 did not allow usage of the Authentication-Info header >>> field >>> (it effectively used RFC 2069). However, we now allow usage of >>> this >>> header field, since it provides integrity checks over the bodies >>> and >>> provides mutual authentication. ... >>> >>> There are now three specifications regarding authentication, RFC >>> 2543, >>> RFC 3261, and "RFC 3261 with the extensions in this document", and >>> you >>> should make clear which spec enables Authentication-Info. The text >>> above seems to say that it is the new draft that enables >>> Authentication-Info, but looking at RFC 3261 clearly shows a >>> specification for its use. >>> >>> ... [HTTP-DIGEST] defines mechanisms for >>> backwards compatibility using the qop attribute in the request. >>> These >>> mechanisms MUST be used by a server to determine if the client >>> supports the new mechanisms in [HTTP-DIGEST] that were not >>> specified >>> in RFC 2069. >>> >>> The connection of remainder of this paragraph to the previous part is >>> unclear to me. It is also unclear what particular "backwards >>> compatibility" is supported "using the qop attribute", as there are >>> now at least two extensions and now two levels of backward >>> compatibility. >>> >>> And given that this seems to be a very general statement about how >>> backwards compatibility (vs. digest auth in 3261) is achieved, it >>> probably should be a separate paragraph. >>> >>> Perhaps this would be clearer to me if I knew off the top of my head >>> the details of the security mechanisms defined in these various >>> documents, and then I would know which document is implied in each >>> reference. But it would be a better exposition if one did not have >>> to >>> be on top of all the details to be able to grasp the overall >>> structure. >>> >>> Also, is "qop" a "directive", a "parameter", or an "attribute"? >>> >>> request-digest = LDQUOT digest-size LHEX RDQUOT >>> digest-size = "32" / "64" >>> >>> This doesn't achieve what you want, since it results in >>> "32a" >>> "62f" >>> being valid request-digest values. The problem is that that in the >>> BNF form "element", "n" must be a literal decimal number. What >>> you >>> intend is >>> request-digest = LDQUOT 32LHEX RDQUOT >>> / LDQUOT 64LHEX RDQUOT >>> But I see in RFC 3261 that response-digest (in Authentication-Info) >>> is >>> syntactically allowed to be variable length: >>> Authentication-Info = "Authentication-Info" HCOLON ainfo >>> *(COMMA ainfo) >>> ainfo = nextnonce / message-qop >>> / response-auth / cnonce >>> / nonce-count >>> nextnonce = "nextnonce" EQUAL nonce-value >>> response-auth = "rspauth" EQUAL response-digest >>> response-digest = LDQUOT *LHEX RDQUOT >>> Why not allow request-digest to be variable length? >>> request-digest = LDQUOT *LHEX RDQUOT >>> That prevents the need for further revisions if a larger digest is >>> ever defined. >>> >>> Dale >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > --089e01628384c2afca04f03c9334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I forgot to mention that I added a new section about forki= ng (section 2.5).

Regards,
=A0Rifaat



On Fri, Jan 17, 2014 at 9:37 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:
Hi Paul,

Thanks for the thorough review.

I have addressed = most of your comments in version -02:

See more inline...

Regards,
=A0Rifaat


<= br>
On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyz= ivat <pkyzivat@alum.mit.edu> wrote:
Rifaat,

The new version is a definite improvement. Now I have more to comment on. := -)

Section 2.1 defines a preference list. How would this be affected by the re= gistration of additional algorithms in the future? ISTM that if there is re= ason to have a "standard" preference list, then it ought to be pa= rt of the registry. (Or perhaps this document should simply state that the = the challenger should list the algorithms it supports in order of strength = of the algorithm.

I changed the text to align with what you have betwee= n the parenthesis.
=A0

Similarly, section 2.2 specifies the size of the digest per algorithm, for = the currently defined algorithms. Again, shouldn't this be part of the = registry, or perhaps there should just be a statement that the registry ref= erences a document that describes the algorithm, and the size of the digest= must be specified as part of the algorithm description.

I will changes the registry in the HTTP draft to add = output size and preference, and see how far we can go with that.
<= div>

In section 2.4, it might be helpful to state that if the UAC doesn't su= pport any of the algorithms in the response that it should abandon attempts= to send this request.

Done

=A0
In section 2.5:

You give a separate definition of H(entity-body) for SHA2-256 and SHA2-512-= 256. But what if some other algorithm from the registry is used? ISTM that = what is needed is a general mechanism, parameterized by the selected algori= thm.

I am not clear on this. All I provided was hashes of = different algorithms for empty string; how would you parameterize that?

=A0
Also, I think specifying this as informal deltas to 3261 is going to cause = a great deal of trouble. I think it would be better to restate most or all = of section 22.4 with the needed changes applied.

Done.

=A0
In section 3:

If there is to be a registry, then I think enumerating the values from the = registry in the ABNF is counter-productive. It will simply lead to confusio= n about what needs to be done to add another algorithm. I suggest something= along the lines of:

=A0 =A0 =A0 algorithm =3D =A0"algorithm" EQUAL (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<digest-alg-name-from-IANA-registry>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ token )

(And I'm debating whether 'token' ought to be there. I think no= t.)

There is then a requirement that new values added to the registry must be c= ompatible with the syntax of 'token'. That will need to go into [HT= TP-DIGEST] that specifies the registry and requirements for adding to it.
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Thanks for your thorough review.

I tried to make the draft short and simple and rely on the HTTP draft
for more details, but that did not seem to work.

I have just submitted a new version of the draft:
http://www.ietf.org/id/draft-yusef-sipcore-digest= -scheme-01.txt

With this version I added more details and described the changes
compared to RFC3261, instead of pointing to the HTTP draft.
I hope this is a bit more clear than the -00 version.

Regards,
=A0 Rifaat




On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley <worley@ariadne.com
<mailto:worley@a= riadne.com>> wrote:

=A0 =A0 It's great that you are writing this!

=A0 =A0 The draft as it is now written references "[HTTP-DIGEST]"= in many
=A0 =A0 places, but does not specify what that *is*. =A0In a sense, this is=
=A0 =A0 unavoidable, since the new HTTP-digest RFC isn't out yet. =A0Bu= t if one
=A0 =A0 is trying to read *this* draft and figure out its significance, one= is
=A0 =A0 blocked by the fact that this draft is written from the point of vi= ew
=A0 =A0 of being the glue that connects an unspecified document to SIP. =A0= One
=A0 =A0 solution would be to insert a note that tells the reader the curren= t
=A0 =A0 draft name for HTTP-DIGEST, a note that would be removed in the for= mal
=A0 =A0 publication.

=A0 =A0 =A0 =A0 Since RFC 2543 is based on HTTP Digest as defined in RFC 20= 69, SIP
=A0 =A0 =A0 =A0 servers supporting [HTTP-DIGEST] MUST ensure they are backw= ards
=A0 =A0 =A0 =A0 compatible with RFC 2069. =A0Procedures for this backwards<= br> =A0 =A0 =A0 =A0 compatibility are specified in [HTTP-DIGEST]. =A0Note, howe= ver, that
=A0 =A0 =A0 =A0 SIP servers MUST NOT accept or request Basic authentication= .

=A0 =A0 It's not clear to me what "are backwards compatible with R= FC 2069"
=A0 =A0 means, because RFC 2069 deals exclusively with HTTP. =A0And similar= ly, a
=A0 =A0 SIP server doesn't support [HTTP-DIGEST] per se either. =A0I th= ink you
=A0 =A0 mean to say, "SIP servers conformant to this specification mus= t be
=A0 =A0 backwards compatible with SIP digest authentication as specified in=
=A0 =A0 RFC 3261 section 22.4 (which is based on RFC 2069). =A0The procedur= es
=A0 =A0 for backward compatibility in SIP are the same as those specified f= or
=A0 =A0 HTTP in [HTTP-DIGEST]."

=A0 =A0 My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies t= o
=A0 =A0 SIP directly; only the modifications of those made by RFC 2543, RFC=
=A0 =A0 3261, and this draft apply to SIP.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Therefore, any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0algorithms that have a dependency on the cno= nce (including
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"MD5-sess", "SHA2-256-sess&qu= ot;, and "SHA2-512-256-sess") require
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that the qop directive be sent. =A0Use of th= e "qop" parameter

=A0 =A0 I think it would read better as "Therefore, any algorithms tha= t
=A0 =A0 require that cnonce be sent (including ...".

=A0 =A0 =A0 =A0 RFC 2543 did not allow usage of the Authentication-Info hea= der field
=A0 =A0 =A0 =A0 (it effectively used RFC 2069). However, we now allow usage= of this
=A0 =A0 =A0 =A0 header field, since it provides integrity checks over the b= odies and
=A0 =A0 =A0 =A0 provides mutual authentication. =A0...

=A0 =A0 There are now three specifications regarding authentication, RFC 25= 43,
=A0 =A0 RFC 3261, and "RFC 3261 with the extensions in this document&q= uot;, and you
=A0 =A0 should make clear which spec enables Authentication-Info. =A0The te= xt
=A0 =A0 above seems to say that it is the new draft that enables
=A0 =A0 Authentication-Info, but looking at RFC 3261 clearly shows a
=A0 =A0 specification for its use.

=A0 =A0 =A0 =A0 ... [HTTP-DIGEST] defines mechanisms for
=A0 =A0 =A0 =A0 backwards compatibility using the qop attribute in the requ= est.
=A0 =A0 These
=A0 =A0 =A0 =A0 mechanisms MUST be used by a server to determine if the cli= ent
=A0 =A0 =A0 =A0 supports the new mechanisms in [HTTP-DIGEST] that were not = specified
=A0 =A0 =A0 =A0 in RFC 2069.

=A0 =A0 The connection of remainder of this paragraph to the previous part = is
=A0 =A0 unclear to me. =A0It is also unclear what particular "backward= s
=A0 =A0 compatibility" is supported "using the qop attribute"= ;, as there are
=A0 =A0 now at least two extensions and now two levels of backward
=A0 =A0 compatibility.

=A0 =A0 And given that this seems to be a very general statement about how<= br> =A0 =A0 backwards compatibility (vs. digest auth in 3261) is achieved, it =A0 =A0 probably should be a separate paragraph.

=A0 =A0 Perhaps this would be clearer to me if I knew off the top of my hea= d
=A0 =A0 the details of the security mechanisms defined in these various
=A0 =A0 documents, and then I would know which document is implied in each<= br> =A0 =A0 reference. =A0But it would be a better exposition if one did not ha= ve to
=A0 =A0 be on top of all the details to be able to grasp the overall
=A0 =A0 structure.

=A0 =A0 Also, is "qop" a "directive", a "parameter= ", or an "attribute"?

=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT digest-size LHEX= RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0digest-size =A0 =A0 =A0 =3D "32" / "6= 4"

=A0 =A0 This doesn't achieve what you want, since it results in
=A0 =A0 =A0 =A0 =A0"32a"
=A0 =A0 =A0 =A0 =A0"62f"
=A0 =A0 being valid request-digest values. =A0The problem is that that in t= he
=A0 =A0 BNF form "<n>element", "n" must be a lite= ral decimal number. =A0What you
=A0 =A0 intend is
=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT 32LHEX RDQUOT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0LDQUOT 64LH= EX RDQUOT
=A0 =A0 But I see in RFC 3261 that response-digest (in Authentication-Info)= is
=A0 =A0 syntactically allowed to be variable length:
=A0 =A0 =A0 =A0 =A0Authentication-Info =A0=3D =A0"Authentication-Info&= quot; HCOLON ainfo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*(COMMA = ainfo)
=A0 =A0 =A0 =A0 =A0ainfo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D =A0nextnonce / = message-qop
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / respo= nse-auth / cnonce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / nonce= -count
=A0 =A0 =A0 =A0 =A0nextnonce =A0 =A0 =A0 =A0 =A0 =A0=3D =A0"nextnonce&= quot; EQUAL nonce-value
=A0 =A0 =A0 =A0 =A0response-auth =A0 =A0 =A0 =A0=3D =A0"rspauth" = EQUAL response-digest
=A0 =A0 =A0 =A0 =A0response-digest =A0 =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT =A0 =A0 Why not allow request-digest to be variable length?
=A0 =A0 =A0 =A0 =A0 =A0request-digest =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT
=A0 =A0 That prevents the need for further revisions if a larger digest is<= br> =A0 =A0 ever defined.

=A0 =A0 Dale




_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


--089e01628384c2afca04f03c9334-- From pkyzivat@alum.mit.edu Sat Jan 18 10:12:54 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5B11A1F19 for ; Sat, 18 Jan 2014 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzDts2IC2d_8 for ; Sat, 18 Jan 2014 10:12:52 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D04771ADF84 for ; Sat, 18 Jan 2014 10:12:51 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id FW2E1n0011c6gX859WCe2d; Sat, 18 Jan 2014 18:12:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id FWCe1n00H3ZTu2S3jWCeMp; Sat, 18 Jan 2014 18:12:38 +0000 Message-ID: <52DAC416.2040707@alum.mit.edu> Date: Sat, 18 Jan 2014 13:12:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390068758; bh=rYs1LerGK4VGM5nJ7NDn1e2N0PZ/EjPHGVaYF5Sgj1E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aEaw6ugdfYV8DC5feZGSpv/61uv4n6g26IImU/Fxo6zEKmK3wokgzMf+tC3nVfBL3 niYW9ndorNjSrDTmrpxyWxKQ+U+0miNMrcwAE7qZwH06sTEYoIM1i7vgBN1B/6pbeu l4bzo9gK5qeS+dSigUhyHHETUARZVCJA4ragVu9p6Tn9qm1OTzvQS4jKyxmOnl/idm eKCh1SYRUWvTEW2+jPLXoU5hWVhK2og9YUSDKsncLFhyOmbZxIAfCNkoP2/KAK35kZ gxxYMMg4lxb93S521FRJzg+LtlKVEiLwhDWWlfYM8raBa9nRw4vW4QAtSwbDLOpb0Y aLhgwUlYcbR4w== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 18:12:54 -0000 Rifaat, It is looking better. More comments: Section 2.6 #6: This gives three formulas for H(entity-body), using different algorithms. This may be confusing to people, especially if they are using some other registered algorithm. And it may lead those who want to register new algorithms to conclude that they need to update this text to include their algorithm. I think what you really are trying to say is: 6. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the hash of an empty string: H(entity-body) = chosen-algorithm("") For example, when the chosen algorithm is SHA2-256, then: H(entity-body) = SHA2-256("") = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" Section 3: request-digest = LDQUOT 32LHEX RDQUOT / LDQUOT 64LHEX RDQUOT This isn't sufficient for future algorithms that require strings of different length. My suggestion is that you simply write this as request-digest = LDQUOT *LHEX RDQUOT And then note in text that the number of hex digits must be specified by the specification of the algorithm used. And, repeating from before: If there is to be a registry, then I think enumerating the values from the registry in the ABNF is counter-productive. It will simply lead to confusion about what needs to be done to add another algorithm. I suggest something along the lines of: algorithm = "algorithm" EQUAL ( / token ) (And I'm debating whether 'token' ought to be there. I think not.) There is then a requirement that new values added to the registry must be compatible with the syntax of 'token'. That will need to go into [HTTP-DIGEST] that specifies the registry and requirements for adding to it. Thanks, Paul On 1/17/14 9:37 PM, Rifaat Shekh-Yusef wrote: > Hi Paul, > > Thanks for the thorough review. > > I have addressed most of your comments in version -02: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-02 > > See more inline... > > Regards, > Rifaat > > > > > On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyzivat > wrote: > > Rifaat, > > The new version is a definite improvement. Now I have more to > comment on. :-) > > Section 2.1 defines a preference list. How would this be affected by > the registration of additional algorithms in the future? ISTM that > if there is reason to have a "standard" preference list, then it > ought to be part of the registry. (Or perhaps this document should > simply state that the the challenger should list the algorithms it > supports in order of strength of the algorithm. > > I changed the text to align with what you have between the parenthesis. > > Similarly, section 2.2 specifies the size of the digest per > algorithm, for the currently defined algorithms. Again, shouldn't > this be part of the registry, or perhaps there should just be a > statement that the registry references a document that describes the > algorithm, and the size of the digest must be specified as part of > the algorithm description. > > I will changes the registry in the HTTP draft to add output size and > preference, and see how far we can go with that. > > > In section 2.4, it might be helpful to state that if the UAC doesn't > support any of the algorithms in the response that it should abandon > attempts to send this request. > > Done > > In section 2.5: > > You give a separate definition of H(entity-body) for SHA2-256 and > SHA2-512-256. But what if some other algorithm from the registry is > used? ISTM that what is needed is a general mechanism, parameterized > by the selected algorithm. > > I am not clear on this. All I provided was hashes of different > algorithms for empty string; how would you parameterize that? > > Also, I think specifying this as informal deltas to 3261 is going to > cause a great deal of trouble. I think it would be better to restate > most or all of section 22.4 with the needed changes applied. > > Done. > > In section 3: > > If there is to be a registry, then I think enumerating the values > from the registry in the ABNF is counter-productive. It will simply > lead to confusion about what needs to be done to add another > algorithm. I suggest something along the lines of: > > algorithm = "algorithm" EQUAL ( > > / token ) > > (And I'm debating whether 'token' ought to be there. I think not.) > > There is then a requirement that new values added to the registry > must be compatible with the syntax of 'token'. That will need to go > into [HTTP-DIGEST] that specifies the registry and requirements for > adding to it. > > Thanks, > Paul > > Thanks for your thorough review. > > I tried to make the draft short and simple and rely on the HTTP > draft > for more details, but that did not seem to work. > > I have just submitted a new version of the draft: > http://www.ietf.org/id/draft-__yusef-sipcore-digest-scheme-__01.txt > > > With this version I added more details and described the changes > compared to RFC3261, instead of pointing to the HTTP draft. > I hope this is a bit more clear than the -00 version. > > Regards, > Rifaat > > > > > On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley > > >> wrote: > > It's great that you are writing this! > > The draft as it is now written references "[HTTP-DIGEST]" > in many > places, but does not specify what that *is*. In a sense, > this is > unavoidable, since the new HTTP-digest RFC isn't out yet. > But if one > is trying to read *this* draft and figure out its > significance, one is > blocked by the fact that this draft is written from the > point of view > of being the glue that connects an unspecified document to > SIP. One > solution would be to insert a note that tells the reader > the current > draft name for HTTP-DIGEST, a note that would be removed in > the formal > publication. > > Since RFC 2543 is based on HTTP Digest as defined in > RFC 2069, SIP > servers supporting [HTTP-DIGEST] MUST ensure they are > backwards > compatible with RFC 2069. Procedures for this backwards > compatibility are specified in [HTTP-DIGEST]. Note, > however, that > SIP servers MUST NOT accept or request Basic > authentication. > > It's not clear to me what "are backwards compatible with > RFC 2069" > means, because RFC 2069 deals exclusively with HTTP. And > similarly, a > SIP server doesn't support [HTTP-DIGEST] per se either. I > think you > mean to say, "SIP servers conformant to this specification > must be > backwards compatible with SIP digest authentication as > specified in > RFC 3261 section 22.4 (which is based on RFC 2069). The > procedures > for backward compatibility in SIP are the same as those > specified for > HTTP in [HTTP-DIGEST]." > > My larger point is that neither RFC 2069 or [HTTP-DIGEST] > applies to > SIP directly; only the modifications of those made by RFC > 2543, RFC > 3261, and this draft apply to SIP. > > Therefore, any > algorithms that have a dependency on the cnonce > (including > "MD5-sess", "SHA2-256-sess", and > "SHA2-512-256-sess") require > that the qop directive be sent. Use of the > "qop" parameter > > I think it would read better as "Therefore, any algorithms that > require that cnonce be sent (including ...". > > RFC 2543 did not allow usage of the Authentication-Info > header field > (it effectively used RFC 2069). However, we now allow > usage of this > header field, since it provides integrity checks over > the bodies and > provides mutual authentication. ... > > There are now three specifications regarding > authentication, RFC 2543, > RFC 3261, and "RFC 3261 with the extensions in this > document", and you > should make clear which spec enables Authentication-Info. > The text > above seems to say that it is the new draft that enables > Authentication-Info, but looking at RFC 3261 clearly shows a > specification for its use. > > ... [HTTP-DIGEST] defines mechanisms for > backwards compatibility using the qop attribute in the > request. > These > mechanisms MUST be used by a server to determine if the > client > supports the new mechanisms in [HTTP-DIGEST] that were > not specified > in RFC 2069. > > The connection of remainder of this paragraph to the > previous part is > unclear to me. It is also unclear what particular "backwards > compatibility" is supported "using the qop attribute", as > there are > now at least two extensions and now two levels of backward > compatibility. > > And given that this seems to be a very general statement > about how > backwards compatibility (vs. digest auth in 3261) is > achieved, it > probably should be a separate paragraph. > > Perhaps this would be clearer to me if I knew off the top > of my head > the details of the security mechanisms defined in these various > documents, and then I would know which document is implied > in each > reference. But it would be a better exposition if one did > not have to > be on top of all the details to be able to grasp the overall > structure. > > Also, is "qop" a "directive", a "parameter", or an "attribute"? > > request-digest = LDQUOT digest-size LHEX RDQUOT > digest-size = "32" / "64" > > This doesn't achieve what you want, since it results in > "32a" > "62f" > being valid request-digest values. The problem is that > that in the > BNF form "element", "n" must be a literal decimal > number. What you > intend is > request-digest = LDQUOT 32LHEX RDQUOT > / LDQUOT 64LHEX RDQUOT > But I see in RFC 3261 that response-digest (in > Authentication-Info) is > syntactically allowed to be variable length: > Authentication-Info = "Authentication-Info" HCOLON ainfo > *(COMMA ainfo) > ainfo = nextnonce / message-qop > / response-auth / cnonce > / nonce-count > nextnonce = "nextnonce" EQUAL nonce-value > response-auth = "rspauth" EQUAL response-digest > response-digest = LDQUOT *LHEX RDQUOT > Why not allow request-digest to be variable length? > request-digest = LDQUOT *LHEX RDQUOT > That prevents the need for further revisions if a larger > digest is > ever defined. > > Dale > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From oej@edvina.net Sun Jan 19 02:50:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89931ADDD0 for ; Sun, 19 Jan 2014 02:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_ZwYzDNQWza for ; Sun, 19 Jan 2014 02:50:37 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 957A51ADDBD for ; Sun, 19 Jan 2014 02:50:35 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E9FB293C2A1; Sun, 19 Jan 2014 10:50:20 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_EC9E0535-E666-45B5-B26D-DAD568A15D27" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 19 Jan 2014 11:50:11 +0100 Message-Id: <6B2A6C02-CBA2-4D96-AD80-00F07EFD315D@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1827) Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 10:50:40 -0000 --Apple-Mail=_EC9E0535-E666-45B5-B26D-DAD568A15D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 15 jan 2014 kl. 00:55 skrev Rifaat Shekh-Yusef : > Another question (assuming "yes" is the response to the above > questions): Are today's SIP UAs really ready to receive multiple > WWW-Authenticate headers (same realm) and select the "best" one? >=20 >=20 > They should, according to the above quote from RFC2617.=20 > We had the same question with regards to the browsers and it turned = out that the browsers were able to handle it properly; browsers give = preference to the header that appears first. "They should" is not the same as "they do". We have seen issues with SIP = UA's not handling authentication in multiple realms in the same request, = like one proxy and one www-auth. I know that Asterisk doesn't handle that properly. I think we really need good implementation guidelines followed by online = SIPit tests in order to make this happen. /O= --Apple-Mail=_EC9E0535-E666-45B5-B26D-DAD568A15D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
15 jan 2014 kl. 00:55 skrev Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com>:
=
Another question (assuming = "yes" is the response to the above
questions): Are today's SIP UAs = really ready to receive multiple
WWW-Authenticate headers (same = realm) and select the "best" one?


They should, according to the above = quote from RFC2617. 
We had the same question with regards to the browsers and it = turned out that the browsers were able to handle it properly; browsers = give preference to the header that appears = first.

"They should" is not the same as = "they do". We have seen issues with SIP UA's not handling authentication = in multiple realms in the same request, like one proxy and one = www-auth.
I know that Asterisk doesn't handle that = properly.

I think we really need good = implementation guidelines followed by online SIPit tests in order to = make this happen.

/O
= --Apple-Mail=_EC9E0535-E666-45B5-B26D-DAD568A15D27-- From rifaat.ietf@gmail.com Sun Jan 19 03:15:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7FE1ADEA1 for ; Sun, 19 Jan 2014 03:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d__hhfzBRT1 for ; Sun, 19 Jan 2014 03:15:26 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 296091ADDBF for ; Sun, 19 Jan 2014 03:15:25 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id e49so2915605eek.29 for ; Sun, 19 Jan 2014 03:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o1mXKHrU3VPPmeNbhM2ThSdT5yQykhRuGtWqjhLwZk0=; b=GF/SPYfns83hD8tM/EtKKlgA80qz7PDmDnRWUglnLyiIGfInwkCRGiM/dPKML8c9P8 9ZUS8Y0pHo+TNGwq0VEUt2bTECYae0ijHeHhaAorzTKeMXmSaXYHf3KznJvbymZkAHBo EMLxxjWECG42IducL4wqqtSnM+AuUiuwLJ3KH3OZdLjpSfBg2267VVC5Yye2+8mXK2uf r/LxWc3SHls1f9+vI2JSgRzS5In9l1JSI4XfDiok9T2Ct2/JlDPRpDzXn2RNANwvq540 xRPdyEwxFZyzQ0G4J76wbUKZ202Kfsp0+DDFr5rotSTZxV+mIhvABdAg1+EA7gnN+562 +PUw== MIME-Version: 1.0 X-Received: by 10.14.199.1 with SMTP id w1mr12191390een.29.1390130112634; Sun, 19 Jan 2014 03:15:12 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 19 Jan 2014 03:15:12 -0800 (PST) In-Reply-To: <6B2A6C02-CBA2-4D96-AD80-00F07EFD315D@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> <6B2A6C02-CBA2-4D96-AD80-00F07EFD315D@edvina.net> Date: Sun, 19 Jan 2014 06:15:12 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=047d7b3440b88e21dc04f050e3e7 Cc: SIPCORE WG Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 11:15:29 -0000 --047d7b3440b88e21dc04f050e3e7 Content-Type: text/plain; charset=ISO-8859-1 I agree, but just to make it clear, this is also an RFC3261 requirement, not only an HTTP requirement. Take a look at the following quote from RFC3261, Section 22.3: If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. Regards, Rifaat On Sun, Jan 19, 2014 at 5:50 AM, Olle E. Johansson wrote: > > 15 jan 2014 kl. 00:55 skrev Rifaat Shekh-Yusef : > > Another question (assuming "yes" is the response to the above >> questions): Are today's SIP UAs really ready to receive multiple >> WWW-Authenticate headers (same realm) and select the "best" one? >> >> > They should, according to the above quote from RFC2617. > We had the same question with regards to the browsers and it turned out > that the browsers were able to handle it properly; browsers give preference > to the header that appears first. > > > "They should" is not the same as "they do". We have seen issues with SIP > UA's not handling authentication in multiple realms in the same request, > like one proxy and one www-auth. > I know that Asterisk doesn't handle that properly. > > I think we really need good implementation guidelines followed by online > SIPit tests in order to make this happen. > > /O > --047d7b3440b88e21dc04f050e3e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree, but just to make it clear, this is also an RFC326= 1 requirement, not only an HTTP requirement.
Take a look at the followi= ng quote from RFC3261, Section 22.3:

   If a =
request is forked (as described in Section 16.7), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.


Regards,
=A0Rifaat



On Sun, Jan 19, 2014 at 5:50 AM, Olle E. Johansson <oej@edvina.net> wrote:

15 jan 2014 kl. 00:55 skr= ev Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

Another question (assuming "yes" is the response to the above
= questions): Are today's SIP UAs really ready to receive multiple
WWW= -Authenticate headers (same realm) and select the "best" one?


They should, according to the above quote from RFC2617.=A0
We had the same question with regards to the browsers and it turned out tha= t the browsers were able to handle it properly; browsers give preference to= the header that appears first.

"They should" is not the same as "they do". We have see= n issues with SIP UA's not handling authentication in multiple realms i= n the same request, like one proxy and one www-auth.
I know that = Asterisk doesn't handle that properly.

I think we really need good implementation guidelines f= ollowed by online SIPit tests in order to make this happen.

/O

--047d7b3440b88e21dc04f050e3e7-- From rifaat.ietf@gmail.com Sun Jan 19 03:43:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649A21ADEA6 for ; Sun, 19 Jan 2014 03:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ck-Zm8XZXDi for ; Sun, 19 Jan 2014 03:43:30 -0800 (PST) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9277B1ADE71 for ; Sun, 19 Jan 2014 03:43:29 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id r15so1696595ead.41 for ; Sun, 19 Jan 2014 03:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7jyrQNtJ82+ZKQGs8yohzoOBP47tmdmrHlBgigjUjX0=; b=o5BzhaMrRJtfWepMEsEpL3wfZjekMJRgXOfqWiBvVENADg2h0nJ715T7gcgsCEanJ3 9xllN7E9Y/1zFY8JARu+oqkSyhQ+l93OkY0UEUHlTsx4+f+fFMj1fgyj29zWZaizHkTS m3o9zp9xgpsRo7a6cpQQ5eORZCEVGrSCw9GV2rKNNyQCkh0x70904MtFX3bhS3I7PIIO F6bOlGgTojBqR048vteLYxFqFqHebAtXgnvbx8I/3HP7pdmwIvwydC+LVI1erePWuImU AWlREZJu5NSQroBuqaZchUHH9SF/NpNjtLc4bGHbAQI5N8/CYwz2jMBIZ3u33V+3Eo+s YGIQ== MIME-Version: 1.0 X-Received: by 10.14.87.195 with SMTP id y43mr12239694eee.32.1390131795835; Sun, 19 Jan 2014 03:43:15 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 19 Jan 2014 03:43:15 -0800 (PST) In-Reply-To: <52DAC416.2040707@alum.mit.edu> References: <52DAC416.2040707@alum.mit.edu> Date: Sun, 19 Jan 2014 06:43:15 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c2997ee1bdf604f05147aa Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 11:43:33 -0000 --001a11c2997ee1bdf604f05147aa Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 18, 2014 at 1:12 PM, Paul Kyzivat wrote: > Rifaat, > > It is looking better. More comments: > > Section 2.6 #6: > > This gives three formulas for H(entity-body), using different algorithms. > This may be confusing to people, especially if they are using some other > registered algorithm. And it may lead those who want to register new > algorithms to conclude that they need to update this text to include their > algorithm. > > I think what you really are trying to say is: > > 6. As a clarification to the calculation of the A2 value for > message integrity assurance in the Digest authentication > scheme, implementers should assume, when the entity-body is > empty (that is, when SIP messages have no body) that the hash > of the entity-body resolves to the hash of an empty > string: > > H(entity-body) = chosen-algorithm("") > > For example, when the chosen algorithm is SHA2-256, then: > > H(entity-body) = SHA2-256("") = > "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" > > Sure. I will do that in the next version of the draft. > Section 3: > > > request-digest = LDQUOT 32LHEX RDQUOT / LDQUOT 64LHEX RDQUOT > > This isn't sufficient for future algorithms that require strings of > different length. My suggestion is that you simply write this as > > > request-digest = LDQUOT *LHEX RDQUOT > > Yeah, I did that with the HTTP draft, but forgot to that for this draft. I will fix it. > And then note in text that the number of hex digits must be specified by > the specification of the algorithm used. > > And, repeating from before: > > > If there is to be a registry, then I think enumerating the values from the > registry in the ABNF is counter-productive. It will simply lead to > confusion about what needs to be done to add another algorithm. I suggest > something along the lines of: > > algorithm = "algorithm" EQUAL ( > > / token ) > > Agree > (And I'm debating whether 'token' ought to be there. I think not.) > > There is then a requirement that new values added to the registry must be > compatible with the syntax of 'token'. That will need to go into > [HTTP-DIGEST] that specifies the registry and requirements for adding to it. > > Here is the IANA registry as defined in the latest HTTP draft: http://tools.ietf.org/html/draft-ietf-httpauth-digest-02#section-6 I am not clear on what you mean by " ...compatible with the syntax of 'token' ". Thanks, Rifaat > Thanks, > Paul > > > On 1/17/14 9:37 PM, Rifaat Shekh-Yusef wrote: > >> Hi Paul, >> >> Thanks for the thorough review. >> >> I have addressed most of your comments in version -02: >> http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-02 >> >> See more inline... >> >> Regards, >> Rifaat >> >> >> >> >> On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyzivat > > wrote: >> >> Rifaat, >> >> The new version is a definite improvement. Now I have more to >> comment on. :-) >> >> Section 2.1 defines a preference list. How would this be affected by >> the registration of additional algorithms in the future? ISTM that >> if there is reason to have a "standard" preference list, then it >> ought to be part of the registry. (Or perhaps this document should >> simply state that the the challenger should list the algorithms it >> supports in order of strength of the algorithm. >> >> I changed the text to align with what you have between the parenthesis. >> >> Similarly, section 2.2 specifies the size of the digest per >> algorithm, for the currently defined algorithms. Again, shouldn't >> this be part of the registry, or perhaps there should just be a >> statement that the registry references a document that describes the >> algorithm, and the size of the digest must be specified as part of >> the algorithm description. >> >> I will changes the registry in the HTTP draft to add output size and >> preference, and see how far we can go with that. >> >> >> In section 2.4, it might be helpful to state that if the UAC doesn't >> support any of the algorithms in the response that it should abandon >> attempts to send this request. >> >> Done >> >> In section 2.5: >> >> You give a separate definition of H(entity-body) for SHA2-256 and >> SHA2-512-256. But what if some other algorithm from the registry is >> used? ISTM that what is needed is a general mechanism, parameterized >> by the selected algorithm. >> >> I am not clear on this. All I provided was hashes of different >> algorithms for empty string; how would you parameterize that? >> >> Also, I think specifying this as informal deltas to 3261 is going to >> cause a great deal of trouble. I think it would be better to restate >> most or all of section 22.4 with the needed changes applied. >> >> Done. >> >> In section 3: >> >> If there is to be a registry, then I think enumerating the values >> from the registry in the ABNF is counter-productive. It will simply >> lead to confusion about what needs to be done to add another >> algorithm. I suggest something along the lines of: >> >> algorithm = "algorithm" EQUAL ( >> >> >> / token ) >> >> (And I'm debating whether 'token' ought to be there. I think not.) >> >> There is then a requirement that new values added to the registry >> must be compatible with the syntax of 'token'. That will need to go >> into [HTTP-DIGEST] that specifies the registry and requirements for >> adding to it. >> >> Thanks, >> Paul >> >> Thanks for your thorough review. >> >> I tried to make the draft short and simple and rely on the HTTP >> draft >> for more details, but that did not seem to work. >> >> I have just submitted a new version of the draft: >> http://www.ietf.org/id/draft-__yusef-sipcore-digest-scheme-_ >> _01.txt >> >> >> >> With this version I added more details and described the changes >> compared to RFC3261, instead of pointing to the HTTP draft. >> I hope this is a bit more clear than the -00 version. >> >> Regards, >> Rifaat >> >> >> >> >> On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley >> >> >> wrote: >> >> It's great that you are writing this! >> >> The draft as it is now written references "[HTTP-DIGEST]" >> in many >> places, but does not specify what that *is*. In a sense, >> this is >> unavoidable, since the new HTTP-digest RFC isn't out yet. >> But if one >> is trying to read *this* draft and figure out its >> significance, one is >> blocked by the fact that this draft is written from the >> point of view >> of being the glue that connects an unspecified document to >> SIP. One >> solution would be to insert a note that tells the reader >> the current >> draft name for HTTP-DIGEST, a note that would be removed in >> the formal >> publication. >> >> Since RFC 2543 is based on HTTP Digest as defined in >> RFC 2069, SIP >> servers supporting [HTTP-DIGEST] MUST ensure they are >> backwards >> compatible with RFC 2069. Procedures for this backwards >> compatibility are specified in [HTTP-DIGEST]. Note, >> however, that >> SIP servers MUST NOT accept or request Basic >> authentication. >> >> It's not clear to me what "are backwards compatible with >> RFC 2069" >> means, because RFC 2069 deals exclusively with HTTP. And >> similarly, a >> SIP server doesn't support [HTTP-DIGEST] per se either. I >> think you >> mean to say, "SIP servers conformant to this specification >> must be >> backwards compatible with SIP digest authentication as >> specified in >> RFC 3261 section 22.4 (which is based on RFC 2069). The >> procedures >> for backward compatibility in SIP are the same as those >> specified for >> HTTP in [HTTP-DIGEST]." >> >> My larger point is that neither RFC 2069 or [HTTP-DIGEST] >> applies to >> SIP directly; only the modifications of those made by RFC >> 2543, RFC >> 3261, and this draft apply to SIP. >> >> Therefore, any >> algorithms that have a dependency on the cnonce >> (including >> "MD5-sess", "SHA2-256-sess", and >> "SHA2-512-256-sess") require >> that the qop directive be sent. Use of the >> "qop" parameter >> >> I think it would read better as "Therefore, any algorithms >> that >> require that cnonce be sent (including ...". >> >> RFC 2543 did not allow usage of the Authentication-Info >> header field >> (it effectively used RFC 2069). However, we now allow >> usage of this >> header field, since it provides integrity checks over >> the bodies and >> provides mutual authentication. ... >> >> There are now three specifications regarding >> authentication, RFC 2543, >> RFC 3261, and "RFC 3261 with the extensions in this >> document", and you >> should make clear which spec enables Authentication-Info. >> The text >> above seems to say that it is the new draft that enables >> Authentication-Info, but looking at RFC 3261 clearly shows a >> specification for its use. >> >> ... [HTTP-DIGEST] defines mechanisms for >> backwards compatibility using the qop attribute in the >> request. >> These >> mechanisms MUST be used by a server to determine if the >> client >> supports the new mechanisms in [HTTP-DIGEST] that were >> not specified >> in RFC 2069. >> >> The connection of remainder of this paragraph to the >> previous part is >> unclear to me. It is also unclear what particular "backwards >> compatibility" is supported "using the qop attribute", as >> there are >> now at least two extensions and now two levels of backward >> compatibility. >> >> And given that this seems to be a very general statement >> about how >> backwards compatibility (vs. digest auth in 3261) is >> achieved, it >> probably should be a separate paragraph. >> >> Perhaps this would be clearer to me if I knew off the top >> of my head >> the details of the security mechanisms defined in these >> various >> documents, and then I would know which document is implied >> in each >> reference. But it would be a better exposition if one did >> not have to >> be on top of all the details to be able to grasp the overall >> structure. >> >> Also, is "qop" a "directive", a "parameter", or an >> "attribute"? >> >> request-digest = LDQUOT digest-size LHEX RDQUOT >> digest-size = "32" / "64" >> >> This doesn't achieve what you want, since it results in >> "32a" >> "62f" >> being valid request-digest values. The problem is that >> that in the >> BNF form "element", "n" must be a literal decimal >> number. What you >> intend is >> request-digest = LDQUOT 32LHEX RDQUOT >> / LDQUOT 64LHEX RDQUOT >> But I see in RFC 3261 that response-digest (in >> Authentication-Info) is >> syntactically allowed to be variable length: >> Authentication-Info = "Authentication-Info" HCOLON >> ainfo >> *(COMMA ainfo) >> ainfo = nextnonce / message-qop >> / response-auth / cnonce >> / nonce-count >> nextnonce = "nextnonce" EQUAL nonce-value >> response-auth = "rspauth" EQUAL response-digest >> response-digest = LDQUOT *LHEX RDQUOT >> Why not allow request-digest to be variable length? >> request-digest = LDQUOT *LHEX RDQUOT >> That prevents the need for further revisions if a larger >> digest is >> ever defined. >> >> Dale >> >> >> >> >> _________________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> _________________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/__listinfo/sipcore >> >> >> >> > --001a11c2997ee1bdf604f05147aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jan 18, 2014 at 1:12 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
Rifaat,

It is looking better. More comments:

Section 2.6 #6:

This gives three formulas for H(entity-body), using different algorithms. T= his may be confusing to people, especially if they are using some other reg= istered algorithm. And it may lead those who want to register new algorithm= s to conclude that they need to update this text to include their algorithm= .

I think what you really are trying to say is:

=A0 =A06. =A0As a clarification to the calculation of the A2 value for
=A0 =A0 =A0 =A0message integrity assurance in the Digest authentication
=A0 =A0 =A0 =A0scheme, implementers should assume, when the entity-body is<= br> =A0 =A0 =A0 =A0empty (that is, when SIP messages have no body) that the has= h
=A0 =A0 =A0 =A0of the entity-body resolves to the hash of an empty
=A0 =A0 =A0 =A0string:

=A0 =A0 =A0 =A0H(entity-body) =3D chosen-algorithm("")

=A0 =A0 =A0 =A0For example, when the chosen algorithm is SHA2-256, then:
=A0 =A0 =A0 =A0H(entity-body) =3D SHA2-256("") =3D
=A0 =A0 =A0 "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649= b934ca495991b7852b855"


Sure. I will do that in the next versi= on of the draft.

=A0
Section 3:


=A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT 32LHEX RDQUOT / LDQUOT 64LH= EX RDQUOT

This isn't sufficient for future algorithms that require strings of dif= ferent length. My suggestion is that you simply write this as


=A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT *LHEX RDQUOT


Yeah, I did that with the HTTP d= raft, but forgot to that for this draft. I will fix it.

=A0
And then note in text that the number of hex digits must be specified by th= e specification of the algorithm used.

And, repeating from before:


If there is to be a registry, then I think enumerating the values from the = registry in the ABNF is counter-productive. It will simply lead to confusio= n about what needs to be done to add another algorithm. I suggest something= along the lines of:

=A0 =A0 =A0 algorithm =3D =A0"algorithm" EQUAL (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<digest-alg-name-from-IANA-registry>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ token )


Agree

<= br>
=A0
(And I'm debating whether 'token' ought to be there. I think no= t.)

There is then a requirement that new values added to the registry must be c= ompatible with the syntax of 'token'. That will need to go into [HT= TP-DIGEST] that specifies the registry and requirements for adding to it.

Here is the IANA registry a= s defined in the latest HTTP draft:

I am not clear on what you mean by " .= ..compatible with the syntax of 'tok= en'=A0".

Thanks,
=A0Rifa= at


=A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 1/17/14 9:37 PM, Rifaat Shekh-Yusef wrote:
Hi Paul,

Thanks for the thorough review.

I have addressed most of your comments in version -02:
http://tools.ietf.org/html/draft-yusef-sipcore-di= gest-scheme-02

See more inline...

Regards,
=A0 Rifaat




On Thu, Jan 16, 2014 at 6:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<= div class=3D"h5"> <mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 Rifaat,

=A0 =A0 The new version is a definite improvement. Now I have more to
=A0 =A0 comment on. :-)

=A0 =A0 Section 2.1 defines a preference list. How would this be affected b= y
=A0 =A0 the registration of additional algorithms in the future? ISTM that<= br> =A0 =A0 if there is reason to have a "standard" preference list, = then it
=A0 =A0 ought to be part of the registry. (Or perhaps this document should<= br> =A0 =A0 simply state that the the challenger should list the algorithms it<= br> =A0 =A0 supports in order of strength of the algorithm.

I changed the text to align with what you have between the parenthesis.

=A0 =A0 Similarly, section 2.2 specifies the size of the digest per
=A0 =A0 algorithm, for the currently defined algorithms. Again, shouldn'= ;t
=A0 =A0 this be part of the registry, or perhaps there should just be a
=A0 =A0 statement that the registry references a document that describes th= e
=A0 =A0 algorithm, and the size of the digest must be specified as part of<= br> =A0 =A0 the algorithm description.

I will changes the registry in the HTTP draft to add output size and
preference, and see how far we can go with that.


=A0 =A0 In section 2.4, it might be helpful to state that if the UAC doesn&= #39;t
=A0 =A0 support any of the algorithms in the response that it should abando= n
=A0 =A0 attempts to send this request.

Done

=A0 =A0 In section 2.5:

=A0 =A0 You give a separate definition of H(entity-body) for SHA2-256 and =A0 =A0 SHA2-512-256. But what if some other algorithm from the registry is=
=A0 =A0 used? ISTM that what is needed is a general mechanism, parameterize= d
=A0 =A0 by the selected algorithm.

I am not clear on this. All I provided was hashes of different
algorithms for empty string; how would you parameterize that?

=A0 =A0 Also, I think specifying this as informal deltas to 3261 is going t= o
=A0 =A0 cause a great deal of trouble. I think it would be better to restat= e
=A0 =A0 most or all of section 22.4 with the needed changes applied.

Done.

=A0 =A0 In section 3:

=A0 =A0 If there is to be a registry, then I think enumerating the values =A0 =A0 from the registry in the ABNF is counter-productive. It will simply=
=A0 =A0 lead to confusion about what needs to be done to add another
=A0 =A0 algorithm. I suggest something along the lines of:

=A0 =A0 =A0 =A0 =A0 =A0algorithm =3D =A0"algorithm" EQUAL (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <digest-alg-name-from-IA= NA-__registry>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / token )

=A0 =A0 (And I'm debating whether 'token' ought to be there. I = think not.)

=A0 =A0 There is then a requirement that new values added to the registry =A0 =A0 must be compatible with the syntax of 'token'. That will ne= ed to go
=A0 =A0 into [HTTP-DIGEST] that specifies the registry and requirements for=
=A0 =A0 adding to it.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 =A0 =A0 Thanks for your thorough review.

=A0 =A0 =A0 =A0 I tried to make the draft short and simple and rely on the = HTTP
=A0 =A0 =A0 =A0 draft
=A0 =A0 =A0 =A0 for more details, but that did not seem to work.

=A0 =A0 =A0 =A0 I have just submitted a new version of the draft:
=A0 =A0 =A0 =A0 http://www.ietf.org/id/draft-__yusef-sipcore-digest-scheme-__01.txt

=A0 =A0 =A0 =A0 <http://www.ietf.org/id/draft-= yusef-sipcore-digest-scheme-01.txt>

=A0 =A0 =A0 =A0 With this version I added more details and described the ch= anges
=A0 =A0 =A0 =A0 compared to RFC3261, instead of pointing to the HTTP draft.=
=A0 =A0 =A0 =A0 I hope this is a bit more clear than the -00 version.

=A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0Rifaat




=A0 =A0 =A0 =A0 On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley
=A0 =A0 =A0 =A0 <worley@ariadne.com <mailto:worley@ariadne.com>
=A0 =A0 =A0 =A0 <mailto:worley@ariadne.com <mailto:worley@ariadne.com>>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0It's great that you are writing this!

=A0 =A0 =A0 =A0 =A0 =A0 =A0The draft as it is now written references "= [HTTP-DIGEST]"
=A0 =A0 =A0 =A0 in many
=A0 =A0 =A0 =A0 =A0 =A0 =A0places, but does not specify what that *is*. =A0= In a sense,
=A0 =A0 =A0 =A0 this is
=A0 =A0 =A0 =A0 =A0 =A0 =A0unavoidable, since the new HTTP-digest RFC isn&#= 39;t out yet.
=A0 =A0 =A0 =A0 =A0 But if one
=A0 =A0 =A0 =A0 =A0 =A0 =A0is trying to read *this* draft and figure out it= s
=A0 =A0 =A0 =A0 significance, one is
=A0 =A0 =A0 =A0 =A0 =A0 =A0blocked by the fact that this draft is written f= rom the
=A0 =A0 =A0 =A0 point of view
=A0 =A0 =A0 =A0 =A0 =A0 =A0of being the glue that connects an unspecified d= ocument to
=A0 =A0 =A0 =A0 SIP. =A0One
=A0 =A0 =A0 =A0 =A0 =A0 =A0solution would be to insert a note that tells th= e reader
=A0 =A0 =A0 =A0 the current
=A0 =A0 =A0 =A0 =A0 =A0 =A0draft name for HTTP-DIGEST, a note that would be= removed in
=A0 =A0 =A0 =A0 the formal
=A0 =A0 =A0 =A0 =A0 =A0 =A0publication.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Since RFC 2543 is based on HTTP Digest a= s defined in
=A0 =A0 =A0 =A0 RFC 2069, SIP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0servers supporting [HTTP-DIGEST] MUST en= sure they are
=A0 =A0 =A0 =A0 backwards
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible with RFC 2069. =A0Procedures = for this backwards
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatibility are specified in [HTTP-DIG= EST]. =A0Note,
=A0 =A0 =A0 =A0 however, that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SIP servers MUST NOT accept or request B= asic
=A0 =A0 =A0 =A0 authentication.

=A0 =A0 =A0 =A0 =A0 =A0 =A0It's not clear to me what "are backward= s compatible with
=A0 =A0 =A0 =A0 RFC 2069"
=A0 =A0 =A0 =A0 =A0 =A0 =A0means, because RFC 2069 deals exclusively with H= TTP. =A0And
=A0 =A0 =A0 =A0 similarly, a
=A0 =A0 =A0 =A0 =A0 =A0 =A0SIP server doesn't support [HTTP-DIGEST] per= se either. =A0I
=A0 =A0 =A0 =A0 think you
=A0 =A0 =A0 =A0 =A0 =A0 =A0mean to say, "SIP servers conformant to thi= s specification
=A0 =A0 =A0 =A0 must be
=A0 =A0 =A0 =A0 =A0 =A0 =A0backwards compatible with SIP digest authenticat= ion as
=A0 =A0 =A0 =A0 specified in
=A0 =A0 =A0 =A0 =A0 =A0 =A0RFC 3261 section 22.4 (which is based on RFC 206= 9). =A0The
=A0 =A0 =A0 =A0 procedures
=A0 =A0 =A0 =A0 =A0 =A0 =A0for backward compatibility in SIP are the same a= s those
=A0 =A0 =A0 =A0 specified for
=A0 =A0 =A0 =A0 =A0 =A0 =A0HTTP in [HTTP-DIGEST]."

=A0 =A0 =A0 =A0 =A0 =A0 =A0My larger point is that neither RFC 2069 or [HTT= P-DIGEST]
=A0 =A0 =A0 =A0 applies to
=A0 =A0 =A0 =A0 =A0 =A0 =A0SIP directly; only the modifications of those ma= de by RFC
=A0 =A0 =A0 =A0 2543, RFC
=A0 =A0 =A0 =A0 =A0 =A0 =A03261, and this draft apply to SIP.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Therefore, any
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 algorithms that have a depe= ndency on the cnonce
=A0 =A0 =A0 =A0 (including
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "MD5-sess", "= ;SHA2-256-sess", and
=A0 =A0 =A0 =A0 "SHA2-512-256-sess") require
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that the qop directive be s= ent. =A0Use of the
=A0 =A0 =A0 =A0 "qop" parameter

=A0 =A0 =A0 =A0 =A0 =A0 =A0I think it would read better as "Therefore,= any algorithms that
=A0 =A0 =A0 =A0 =A0 =A0 =A0require that cnonce be sent (including ..."= .

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC 2543 did not allow usage of the Auth= entication-Info
=A0 =A0 =A0 =A0 header field
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(it effectively used RFC 2069). However,= we now allow
=A0 =A0 =A0 =A0 usage of this
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0header field, since it provides integrit= y checks over
=A0 =A0 =A0 =A0 the bodies and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0provides mutual authentication. =A0...
=A0 =A0 =A0 =A0 =A0 =A0 =A0There are now three specifications regarding
=A0 =A0 =A0 =A0 authentication, RFC 2543,
=A0 =A0 =A0 =A0 =A0 =A0 =A0RFC 3261, and "RFC 3261 with the extensions= in this
=A0 =A0 =A0 =A0 document", and you
=A0 =A0 =A0 =A0 =A0 =A0 =A0should make clear which spec enables Authenticat= ion-Info.
=A0 =A0 =A0 =A0 =A0 The text
=A0 =A0 =A0 =A0 =A0 =A0 =A0above seems to say that it is the new draft that= enables
=A0 =A0 =A0 =A0 =A0 =A0 =A0Authentication-Info, but looking at RFC 3261 cle= arly shows a
=A0 =A0 =A0 =A0 =A0 =A0 =A0specification for its use.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... [HTTP-DIGEST] defines mechanisms for=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0backwards compatibility using the qop at= tribute in the
=A0 =A0 =A0 =A0 request.
=A0 =A0 =A0 =A0 =A0 =A0 =A0These
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mechanisms MUST be used by a server to d= etermine if the
=A0 =A0 =A0 =A0 client
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0supports the new mechanisms in [HTTP-DIG= EST] that were
=A0 =A0 =A0 =A0 not specified
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in RFC 2069.

=A0 =A0 =A0 =A0 =A0 =A0 =A0The connection of remainder of this paragraph to= the
=A0 =A0 =A0 =A0 previous part is
=A0 =A0 =A0 =A0 =A0 =A0 =A0unclear to me. =A0It is also unclear what partic= ular "backwards
=A0 =A0 =A0 =A0 =A0 =A0 =A0compatibility" is supported "using the= qop attribute", as
=A0 =A0 =A0 =A0 there are
=A0 =A0 =A0 =A0 =A0 =A0 =A0now at least two extensions and now two levels o= f backward
=A0 =A0 =A0 =A0 =A0 =A0 =A0compatibility.

=A0 =A0 =A0 =A0 =A0 =A0 =A0And given that this seems to be a very general s= tatement
=A0 =A0 =A0 =A0 about how
=A0 =A0 =A0 =A0 =A0 =A0 =A0backwards compatibility (vs. digest auth in 3261= ) is
=A0 =A0 =A0 =A0 achieved, it
=A0 =A0 =A0 =A0 =A0 =A0 =A0probably should be a separate paragraph.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Perhaps this would be clearer to me if I knew of= f the top
=A0 =A0 =A0 =A0 of my head
=A0 =A0 =A0 =A0 =A0 =A0 =A0the details of the security mechanisms defined i= n these various
=A0 =A0 =A0 =A0 =A0 =A0 =A0documents, and then I would know which document = is implied
=A0 =A0 =A0 =A0 in each
=A0 =A0 =A0 =A0 =A0 =A0 =A0reference. =A0But it would be a better expositio= n if one did
=A0 =A0 =A0 =A0 not have to
=A0 =A0 =A0 =A0 =A0 =A0 =A0be on top of all the details to be able to grasp= the overall
=A0 =A0 =A0 =A0 =A0 =A0 =A0structure.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Also, is "qop" a "directive"= , a "parameter", or an "attribute"?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT= digest-size LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 digest-size =A0 =A0 =A0 =3D "3= 2" / "64"

=A0 =A0 =A0 =A0 =A0 =A0 =A0This doesn't achieve what you want, since it= results in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "32a"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "62f"
=A0 =A0 =A0 =A0 =A0 =A0 =A0being valid request-digest values. =A0The proble= m is that
=A0 =A0 =A0 =A0 that in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0BNF form "<n>element", "n&q= uot; must be a literal decimal
=A0 =A0 =A0 =A0 number. =A0What you
=A0 =A0 =A0 =A0 =A0 =A0 =A0intend is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT= 32LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= / =A0LDQUOT 64LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0But I see in RFC 3261 that response-digest (in =A0 =A0 =A0 =A0 Authentication-Info) is
=A0 =A0 =A0 =A0 =A0 =A0 =A0syntactically allowed to be variable length:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Authentication-Info =A0=3D =A0"Aut= hentication-Info" HCOLON ainfo
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 *(COMMA ainfo)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ainfo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =3D =A0nextnonce / message-qop
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0/ response-auth / cnonce
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0/ nonce-count
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nextnonce =A0 =A0 =A0 =A0 =A0 =A0=3D = =A0"nextnonce" EQUAL nonce-value
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response-auth =A0 =A0 =A0 =A0=3D =A0&qu= ot;rspauth" EQUAL response-digest
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 response-digest =A0 =A0 =A0=3D =A0LDQUO= T *LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0Why not allow request-digest to be variable leng= th?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 request-digest =A0 =A0=3D =A0LDQUOT= *LHEX RDQUOT
=A0 =A0 =A0 =A0 =A0 =A0 =A0That prevents the need for further revisions if = a larger
=A0 =A0 =A0 =A0 digest is
=A0 =A0 =A0 =A0 =A0 =A0 =A0ever defined.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Dale




=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 sipcore mailing list
=A0 =A0 =A0 =A0 sipco= re@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/sipcore
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/sipcore>


=A0 =A0 _________________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/sipcore
=A0 =A0 <https://www.ietf.org/mailman/listinfo/sipcore>



--001a11c2997ee1bdf604f05147aa-- From oej@edvina.net Sun Jan 19 06:03:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91251AD8DA for ; Sun, 19 Jan 2014 06:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1LAOKxK4x4M for ; Sun, 19 Jan 2014 06:03:38 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 97CBE1AD68A for ; Sun, 19 Jan 2014 06:03:36 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 508BE93C2A1; Sun, 19 Jan 2014 14:03:22 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_3FA06CA1-405A-4D4E-AE4F-4500AF5752BF" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Sun, 19 Jan 2014 15:03:21 +0100 Message-Id: <044DB656-6C32-4783-94EA-37E28BEAA4B8@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <2035CCE9-08BB-483B-980C-3DF2B9C02244@edvina.net> <52D57935.1070204@alum.mit.edu> <6B2A6C02-CBA2-4D96-AD80-00F07EFD315D@edvina.net> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1827) Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 14:03:41 -0000 --Apple-Mail=_3FA06CA1-405A-4D4E-AE4F-4500AF5752BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 19 jan 2014 kl. 12:15 skrev Rifaat Shekh-Yusef : > I agree, but just to make it clear, this is also an RFC3261 = requirement, not only an HTTP requirement. > Take a look at the following quote from RFC3261, Section 22.3: >=20 > If a request is forked (as described in Section 16.7), various = proxy > servers and/or UAs may wish to challenge the UAC. In this case, = the > forking proxy server is responsible for aggregating these = challenges > into a single response. Each WWW-Authenticate and = Proxy-Authenticate > value received in responses to the forked request MUST be placed = into > the single response that is sent by the forking proxy to the UA; = the > ordering of these header field values is not significant. >=20 I agree fully. We have set up tests for this at SIPit, but haven't = forced the issue as very few UAs support it. We do need to fix that. /O > Regards, > Rifaat >=20 >=20 >=20 > On Sun, Jan 19, 2014 at 5:50 AM, Olle E. Johansson = wrote: >=20 > 15 jan 2014 kl. 00:55 skrev Rifaat Shekh-Yusef = : >=20 >> Another question (assuming "yes" is the response to the above >> questions): Are today's SIP UAs really ready to receive multiple >> WWW-Authenticate headers (same realm) and select the "best" one? >>=20 >>=20 >> They should, according to the above quote from RFC2617.=20 >> We had the same question with regards to the browsers and it turned = out that the browsers were able to handle it properly; browsers give = preference to the header that appears first. >=20 > "They should" is not the same as "they do". We have seen issues with = SIP UA's not handling authentication in multiple realms in the same = request, like one proxy and one www-auth. > I know that Asterisk doesn't handle that properly. >=20 > I think we really need good implementation guidelines followed by = online SIPit tests in order to make this happen. >=20 > /O >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_3FA06CA1-405A-4D4E-AE4F-4500AF5752BF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
19 jan 2014 kl. 12:15 skrev Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

I agree, but just to make it clear, this is also an RFC3261 requirement, not only an HTTP requirement.
Take a look at the following quote from RFC3261, Section 22.3:

   If a request is forked (as described in Section 16.7), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.

I agree fully. We have set up tests for this at SIPit, but haven't forced the issue as very few UAs
support it. We do need to fix that.

/O
Regards,
 Rifaat



On Sun, Jan 19, 2014 at 5:50 AM, Olle E. Johansson <oej@edvina.net> wrote:

15 jan 2014 kl. 00:55 skrev Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

Another question (assuming "yes" is the response to the above
questions): Are today's SIP UAs really ready to receive multiple
WWW-Authenticate headers (same realm) and select the "best" one?


They should, according to the above quote from RFC2617. 
We had the same question with regards to the browsers and it turned out that the browsers were able to handle it properly; browsers give preference to the header that appears first.

"They should" is not the same as "they do". We have seen issues with SIP UA's not handling authentication in multiple realms in the same request, like one proxy and one www-auth.
I know that Asterisk doesn't handle that properly.

I think we really need good implementation guidelines followed by online SIPit tests in order to make this happen.

/O


---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden



--Apple-Mail=_3FA06CA1-405A-4D4E-AE4F-4500AF5752BF-- From oej@edvina.net Sun Jan 19 06:08:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82B1AD8DA for ; Sun, 19 Jan 2014 06:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CwLOXxuJY6G for ; Sun, 19 Jan 2014 06:08:18 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A8FB61ACCE5 for ; Sun, 19 Jan 2014 06:08:17 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E569593C2A1; Sun, 19 Jan 2014 14:08:03 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_91742552-FDE8-4BCD-8BB6-C9555836568A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> Date: Sun, 19 Jan 2014 15:08:02 +0100 Message-Id: <84CEBB5A-26E9-4F92-95C0-00BF999C8AB3@edvina.net> References: <20140111004507.20997.10052.idtracker@ietfa.amsl.com> <201401151951.s0FJpbNX2862598@shell01.TheWorld.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1827) Cc: SIPCORE WG , Olle E Johansson , Rifaat Shekh-Yusef Subject: Re: [sipcore] draft-yusef-sipcore-digest-scheme-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 14:08:19 -0000 --Apple-Mail=_91742552-FDE8-4BCD-8BB6-C9555836568A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 15 jan 2014 kl. 20:51 skrev Dale R. Worley : > Perhaps this would be clearer to me if I knew off the top of my head > the details of the security mechanisms defined in these various > documents, and then I would know which document is implied in each > reference. But it would be a better exposition if one did not have to > be on top of all the details to be able to grasp the overall > structure. Ir Dale doesn't understand this off the top of his head, we clearly need = very clear implementor guidelines - maybe in an appendix. /O= --Apple-Mail=_91742552-FDE8-4BCD-8BB6-C9555836568A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
15 jan 2014 kl. 20:51 skrev Dale R. = Worley <worley@ariadne.com>:

Perhaps this would be clearer to me if I knew off the top = of my head
the details of the security mechanisms defined in these = various
documents, and then I would know which document is implied = in each
reference.  But it would be a better exposition if one = did not have to
be on top of all the details to be able to grasp the = overall
structure.

Ir Dale = doesn't understand this off the top of his head, we clearly need very = clear
implementor guidelines - maybe in an = appendix.

/O
= --Apple-Mail=_91742552-FDE8-4BCD-8BB6-C9555836568A-- From rifaat.ietf@gmail.com Mon Jan 20 06:07:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B96E1A0178 for ; Mon, 20 Jan 2014 06:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2hlmHudv36s for ; Mon, 20 Jan 2014 06:07:37 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2431A017A for ; Mon, 20 Jan 2014 06:07:37 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id h10so3130856eak.2 for ; Mon, 20 Jan 2014 06:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wz1Tc2/vtdjEbTwTpPJVlirqNWbmT8mzaMR5kWjMcU4=; b=nKjeeeQxtBRsPwygS0Z4PMCS+Dn//iD2A1G4uTcAQVtdf7hkoqjOd/J5IBko/YdGjL +1TFy0YlZuzIuC8M5akeTwKPApGSzXguErm5mifuVgNLXwX9hxV1y2AkfUjHUSFfJd4U IjQG3gNpDgJps2oMULiKc7u6VGPiWN2iHmSB/2m3Icnf1s6JVClwD1GM5SBkHAKNTyVI F6zL7QjCXpkmsu+O1Fh42yxwS2phOW5I6/zLVYNFm6a0lY6PUM9hRU3XVS7XC6L/rXni xy13vZjQXHo9/fkwWOIQ92xF/QJ9oMOyWHwv0TMl/v9DJQ8UPSF1FUAscdYIlYbOkVgB CT2A== MIME-Version: 1.0 X-Received: by 10.14.214.200 with SMTP id c48mr102391eep.115.1390226857363; Mon, 20 Jan 2014 06:07:37 -0800 (PST) Received: by 10.14.53.78 with HTTP; Mon, 20 Jan 2014 06:07:37 -0800 (PST) In-Reply-To: <20140120140521.707.25255.idtracker@ietfa.amsl.com> References: <20140120140521.707.25255.idtracker@ietfa.amsl.com> Date: Mon, 20 Jan 2014 09:07:37 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=047d7b622866fd8c9b04f06769aa Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 14:07:39 -0000 --047d7b622866fd8c9b04f06769aa Content-Type: text/plain; charset=ISO-8859-1 Hi, I think that with this version I have addressed all the comments I received so far. Please, take a look and let me know if you have any further comments. Regards, Rifaat On Mon, Jan 20, 2014 at 9:05 AM, wrote: > > A new version of I-D, draft-yusef-sipcore-digest-scheme-03.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-digest-scheme > Revision: 03 > Title: The Session Initiation Protocol (SIP) Digest > Authentication Scheme > Document date: 2014-01-20 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-03.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > Htmlized: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore-digest-scheme-03 > > Abstract: > This document updates the Digest Access Authentication scheme used by > the Session Initiation Protocol (SIP) to add support for SHA2 digest > algorithms to replace the MD5 algorithm. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --047d7b622866fd8c9b04f06769aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think that with this version I ha= ve addressed all the comments I received so far.
Please, take a l= ook and let me know if you have any further comments.

Regards,
=A0Rifaat




On Mon, Jan 20, 201= 4 at 9:05 AM, <internet-drafts@ietf.org> wrote:

A new version of I-D, draft-yusef-sipcore-digest-scheme-03.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
Revision: =A0 =A0 =A0 03
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Digest Auth= entication Scheme
Document date: =A02014-01-20
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A08
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-yusef-sipcore-digest-scheme-03.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-y= usef-sipcore-digest-scheme-03
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rf= cdiff?url2=3Ddraft-yusef-sipcore-digest-scheme-03

Abstract:
=A0 =A0This document updates the Digest Access Authentication scheme used b= y
=A0 =A0the Session Initiation Protocol (SIP) to add support for SHA2 digest=
=A0 =A0algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b622866fd8c9b04f06769aa-- From pkyzivat@alum.mit.edu Mon Jan 20 08:33:43 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64381A01C1 for ; Mon, 20 Jan 2014 08:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxC3AoOkpUK0 for ; Mon, 20 Jan 2014 08:33:42 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8F41A01BF for ; Mon, 20 Jan 2014 08:33:41 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id GDhS1n0071GhbT85BGZhg0; Mon, 20 Jan 2014 16:33:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id GGZh1n00P3ZTu2S3TGZhQe; Mon, 20 Jan 2014 16:33:41 +0000 Message-ID: <52DD4FE5.2060009@alum.mit.edu> Date: Mon, 20 Jan 2014 11:33:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140120140521.707.25255.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390235621; bh=CK8B1+3PEPIJoqu7/gQhJ3q9BjOgSHB5aze9Xxdiok0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Sd+bgnDWCVtlZdHnnR5a7GnPgleaO2DKEePeYgsyfVJcQatcETMLQt0J2RnyQVSC7 Z9Te0IT6aStRg9mgvzoJEMobvk+uac8BQtC/TIPvH1v8n7pml0Zo/b5WeNXnaPEe8Y D97jf9E8k8EuixmyELXtOYM+K1ZQ8eYfHUkN8RLAozRoYl1ZUQwy10ZbgmfIsA/+0c 9s6Th8/YfMxkVnj6roiW7NPKm2jKr/JcfSvbjwBh7vJki2Gh880emquQL9lioEqOl9 T7vbhb2cKLG1JrJQN6DHcl6GpSk5BXmsr3dxxrT6fZIB2rNaSwFGHySWmNEWCoyh/d mBL5/8h7K4S2Q== Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:33:44 -0000 On 1/20/14 9:07 AM, Rifaat Shekh-Yusef wrote: > Hi, > > I think that with this version I have addressed all the comments I > received so far. > Please, take a look and let me know if you have any further comments. I think this covers my concerns with this document. But I'm now too close to it, so I want to hear what others have to day. My concern now moves to draft-ietf-httpauth-digest, which I guess is being discussed in a wg I don't follow. I have some of the same issues with it - that while there is a registry, the text is specific to particular algorithms, not to an arbitrary registered algorithm. And whether there is sufficient information in the registry. (Maybe there is, I'm just not sure.) I see that "Preference" is in the registry. Because these values are sequential integers, there may be a problem if a new algorithm needs to fit in between two existing ones. As things stand, that would require renumbering some of the existing ones. That is a little messy. Perhaps you could make the preference be a real number, so that it would always be possible to slip a new value between any two existing values. Also, in some cases the choice of priority value may be controversial. With the registration policy being "Specification Required", the decision would ultimately be up to the designated expert. May want to think about that - is that appropriate? Or do we need IETF Review for that? Thanks, Paul > Regards, > Rifaat > > > > > On Mon, Jan 20, 2014 at 9:05 AM, > wrote: > > > A new version of I-D, draft-yusef-sipcore-digest-scheme-03.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-digest-scheme > Revision: 03 > Title: The Session Initiation Protocol (SIP) Digest > Authentication Scheme > Document date: 2014-01-20 > Group: Individual Submission > Pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-03.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > Htmlized: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore-digest-scheme-03 > > Abstract: > This document updates the Digest Access Authentication scheme > used by > the Session Initiation Protocol (SIP) to add support for SHA2 digest > algorithms to replace the MD5 algorithm. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Mon Jan 20 10:40:31 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882A21A022C for ; Mon, 20 Jan 2014 10:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_g7IS-H6Yp3 for ; Mon, 20 Jan 2014 10:40:29 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id C91031A0232 for ; Mon, 20 Jan 2014 10:40:28 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id l9so2866392eaj.14 for ; Mon, 20 Jan 2014 10:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ABub38RXyS/PdJ0xmaC8wObuo6uFUoxBieLXXdHSdBs=; b=FLK2wl8h9QSJV3t3vKS5A+gHp+h1DGo8BIb3ZGufCX5aPTvSz7N0wOoygSuyqYL8OJ C639gFHd3sl1XVJdazTnIFyy2dquykBYO0onEMEloykelHlBRctFVVXmR+quVCQ6qgPA tbBowL+HbOem2VkWh4NFtKkkBvNbz31ssy+dpIfoi1ho94MeCZB7Qb3Fi91UnxQ8XYLD PkzpPDDJX5daZEJoBtk6z1p3J9MUnH8HuWsLaiun1q/NNV3NSkoKuTPLzWNU6uHSE9Hl lk9mU2H4bccCnWlWLKifum/69c0CJz0H7KZ2gwZHzcWAfzh06TWK3IWQuxuvZU1eMiCs OWgQ== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr13956378eew.61.1390243193514; Mon, 20 Jan 2014 10:39:53 -0800 (PST) Received: by 10.14.53.78 with HTTP; Mon, 20 Jan 2014 10:39:53 -0800 (PST) In-Reply-To: <52DD4FE5.2060009@alum.mit.edu> References: <20140120140521.707.25255.idtracker@ietfa.amsl.com> <52DD4FE5.2060009@alum.mit.edu> Date: Mon, 20 Jan 2014 13:39:53 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c3fb70b36faf04f06b3798 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:40:31 -0000 --001a11c3fb70b36faf04f06b3798 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Mon, Jan 20, 2014 at 11:33 AM, Paul Kyzivat wrote: > On 1/20/14 9:07 AM, Rifaat Shekh-Yusef wrote: > >> Hi, >> >> I think that with this version I have addressed all the comments I >> received so far. >> Please, take a look and let me know if you have any further comments. >> > > I think this covers my concerns with this document. But I'm now too close > to it, so I want to hear what others have to day. > > My concern now moves to draft-ietf-httpauth-digest, which I guess is being > discussed in a wg I don't follow. I have some of the same issues with it - > that while there is a registry, the text is specific to particular > algorithms, not to an arbitrary registered algorithm. And whether there is > sufficient information in the registry. (Maybe there is, I'm just not sure.) > > Yes, you are right. I am planning on fixing the text in the next version of the draft. > I see that "Preference" is in the registry. Because these values are > sequential integers, there may be a problem if a new algorithm needs to fit > in between two existing ones. As things stand, that would require > renumbering some of the existing ones. That is a little messy. Perhaps you > could make the preference be a real number, so that it would always be > possible to slip a new value between any two existing values. > > I was thinking about that too, and I was considering making the Preference a series with a step of 10 or 100 to address this issue. But using real numbers is probably a better idea as it is unbounded, although I am not sure that is really needed, the unbounded aspect that is. > Also, in some cases the choice of priority value may be controversial. > With the registration policy being "Specification Required", the decision > would ultimately be up to the designated expert. May want to think about > that - is that appropriate? Or do we need IETF Review for that? > > Ok. I need to read the document that describes the various options to refresh my memory with all available options and the implication of each one. > Thanks, > Paul > > > Regards, >> Rifaat >> >> >> >> >> On Mon, Jan 20, 2014 at 9:05 AM, > > wrote: >> >> >> A new version of I-D, draft-yusef-sipcore-digest-scheme-03.txt >> has been successfully submitted by Rifaat Shekh-Yusef and posted to >> the >> IETF repository. >> >> Name: draft-yusef-sipcore-digest-scheme >> Revision: 03 >> Title: The Session Initiation Protocol (SIP) Digest >> Authentication Scheme >> Document date: 2014-01-20 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-yusef-sipcore- >> digest-scheme-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >> Htmlized: >> http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-03 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore-digest-scheme-03 >> >> Abstract: >> This document updates the Digest Access Authentication scheme >> used by >> the Session Initiation Protocol (SIP) to add support for SHA2 >> digest >> algorithms to replace the MD5 algorithm. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c3fb70b36faf04f06b3798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Mon, Jan 20, 2014 at 11:33 AM, Paul Kyzivat = <pkyzivat@alum.mit.edu> wrote:
On 1/20/14 9:07 AM, Rifaat= Shekh-Yusef wrote:
Hi,

I think that with this version I have addressed all the comments I
received so far.
Please, take a look and let me know if you have any further comments.

I think this covers my concerns with this document. But I'm now too clo= se to it, so I want to hear what others have to day.

My concern now moves to draft-ietf-httpauth-digest, which I guess is being = discussed in a wg I don't follow. I have some of the same issues with i= t - that while there is a registry, the text is specific to particular algo= rithms, not to an arbitrary registered algorithm. And whether there is suff= icient information in the registry. (Maybe there is, I'm just not sure.= )

Yes, you are right. I am planning on fixing the text = in the next version of the draft.

=A0
I see that "Preference" is in the registry. Because these values = are sequential integers, there may be a problem if a new algorithm needs to= fit in between two existing ones. As things stand, that would require renu= mbering some of the existing ones. That is a little messy. Perhaps you coul= d make the preference be a real number, so that it would always be possible= to slip a new value between any two existing values.

I was thinking about that too, and I was considering = making the Preference a series with a step of 10 or 100 to address this iss= ue. But using real numbers is probably a better idea as it is unbounded, al= though I am not sure that is really needed, the unbounded aspect that is.

=A0
Also, in some cases the choice of priority value may be controversial. With= the registration policy being "Specification Required", the deci= sion would ultimately be up to the designated expert. May want to think abo= ut that - is that appropriate? Or do we need IETF Review for that?

Ok. I need to read the document that describes the va= rious options to refresh my memory with all available options and the impli= cation of each one.

=A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


Regards,
=A0 Rifaat




On Mon, Jan 20, 2014 at 9:05 AM, <internet-drafts@ietf.org
<mailto:in= ternet-drafts@ietf.org>> wrote:


=A0 =A0 A new version of I-D, draft-yusef-sipcore-digest-scheme-03.t= xt
=A0 =A0 has been successfully submitted by Rifaat Shekh-Yusef and posted to= the
=A0 =A0 IETF repository.

=A0 =A0 Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme<= br> =A0 =A0 Revision: =A0 =A0 =A0 03
=A0 =A0 Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Dig= est
=A0 =A0 Authentication Scheme
=A0 =A0 Document date: =A02014-01-20
=A0 =A0 Group: =A0 =A0 =A0 =A0 =A0Individual Submission
=A0 =A0 Pages: =A0 =A0 =A0 =A0 =A08
=A0 =A0 URL:
=A0 =A0 http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-03.txt
=A0 =A0 Status:
=A0 =A0 https://datatracker.ietf.org/doc/draf= t-yusef-sipcore-digest-scheme/
=A0 =A0 Htmlized:
=A0 =A0 http://tools.ietf.org/html/draft-yusef-si= pcore-digest-scheme-03
=A0 =A0 Diff:
=A0 =A0 http://www.ietf.org/rfcdiff?url2= =3Ddraft-yusef-sipcore-digest-scheme-03

=A0 =A0 Abstract:
=A0 =A0 =A0 =A0 This document updates the Digest Access Authentication sche= me
=A0 =A0 used by
=A0 =A0 =A0 =A0 the Session Initiation Protocol (SIP) to add support for SH= A2 digest
=A0 =A0 =A0 =A0 algorithms to replace the MD5 algorithm.





=A0 =A0 Please note that it may take a couple of minutes from the time of =A0 =A0 submission
=A0 =A0 until the htmlized version and diff are available at tools.ietf.org
=A0 =A0 <http://tool= s.ietf.org>.

=A0 =A0 The IETF Secretariat




_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c3fb70b36faf04f06b3798-- From adam@nostrum.com Tue Jan 21 14:17:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D93E1A01BB for ; Tue, 21 Jan 2014 14:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er8rrIEzYIVc for ; Tue, 21 Jan 2014 14:17:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23EDD1A0127 for ; Tue, 21 Jan 2014 14:17:40 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0LMHMXQ030861 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 16:17:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52DEF1ED.8040905@nostrum.com> Date: Tue, 21 Jan 2014 16:17:17 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Kyzivat , "DRAGE, Keith (Keith)" , "Cullen Jennings (fluffy)" References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> In-Reply-To: <52B1D794.1080602@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: SIPCORE WG , "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:17:42 -0000 It's really quite silly that we're blocked on a trivial matter of terminology here. Grabbing my thesaurus, I suggest: June 2014 Request publication of procedures to amend RFC3263 and RFC6157 for dual-stack client and server handling of SIP URIs containing domain names (PS) Does that work for everyone? /a On 12/18/13 11:12, Paul Kyzivat wrote: > On 12/17/13 6:54 PM, DRAGE, Keith (Keith) wrote: >> I said in a previous mail that I would like to avoid the use of the >> word "supplement" and did suggest alternative wording. My reason is >> that some SDOs treat the word "supplement" as identifying informative >> material, and given that you want reuse in other SDOs it is best not >> to confuse the issue. > > I don't see why that should prevent us from using "supplement" in this > context. We can have that discussion again if the word is used in a > draft, but I don't see why it's a concern there either. (The > definitive indication is whether the RFC is standards track, and the > normative language in the draft.) > >> In any case I don't think we need to bring out in either the title or >> the milestone the exact relationship with RFC 3263, only that one >> exists. Defining that relationship more accurately belongs to the >> abstract. > > My latest proposal was: > > June 2014 Request publication of procedures to supplement RFC3263 > and RFC6157 for dual-stack client and server handling of SIP URIs > containing domain names (PS) > > Your earlier proposal was: "Use of RFC 3263 in dual-stack devices". > > RFC6157 already addresses dual-stack devices. What we are trying to > deal with is that 3263 and 6157 are insufficient and/or wrong for > dual-stack clients. I see no way to avoid using *some* verb - > supplement, update, clarify, expand, ... > > Feel free to offer something that addresses both your concerns and the > others that have been raised. > > Thanks, > Paul > > >> Keith >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 16 December 2013 20:01 >>> To: Cullen Jennings (fluffy) >>> Cc: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith); >>> SIPCORE WG; Olle E. Johansson >>> Subject: Re: [sipcore] IPv6 in the sip core wg >>> >>> On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: >>>> >>>> On Dec 13, 2013, at 9:28 AM, Paul Kyzivat >>> wrote: >>>> >>>>> Having said that, I suggest the following as the milestone: >>>>> >>>>> May 2014 WGLC of procedures to supplement RFC3263 for >>> dual-stack >>>>> client and server handling of SIP URIs containing domain names >>>>> (PS) >>>> >>>> Good with me. And if you want to change "WGLC of" to >>> "Request publication of" that seems like it would fix the >>> point Mary raised. >>> >>> OK. Latest candidate is: >>> >>> June 2014 Request publication of procedures to >>> supplement RFC3263 >>> for dual-stack client and server handling of SIP URIs containing >>> domain names (PS) >>> >>> (I put back the extra month for Mary.) >>> >>> Richard - does this work for you? >>> >>> Thanks, >>> Paul >>> >>> >>> >>> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From fluffy@cisco.com Tue Jan 21 14:24:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FCA1A0244 for ; Tue, 21 Jan 2014 14:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHqAc-9eui7g for ; Tue, 21 Jan 2014 14:24:50 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 890131A01F6 for ; Tue, 21 Jan 2014 14:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3944; q=dns/txt; s=iport; t=1390343090; x=1391552690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=koftewzfZeGSR+pg7LCIFhzVz/+2DxPBl2/98I5ZOFE=; b=ejcp8pFgGjMx9tvLWjwbXDa9CT0fvzORoP6uQMpVKE2XkZSSUOhI9yhH lWbxtQQJ1pkcr7Bvk1aaENE++ou7UAZDNY1arAigPs1RN8Xu2ZT4owA42 VfDVtZBHoFYh63xKw3f1qAbSERvTMXppnLVMSHPdqqre6gShopzMZ3YaM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHjz3lKtJV2b/2dsb2JhbABagws4VrsgT4EWFnSCJQEBAQMBAQEBNzQEBwUHBAIBCBEEAQEBHgkHJwsUCQgCBA4Fh30IDcJrEwSOLgEBHDMHBoMegRQEmCKSGIMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14484014" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 21 Jan 2014 22:24:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMOoMi015047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 22:24:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 16:24:49 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHPFvaWweN12un03EeAE6wmKKHd45qQJd8A Date: Tue, 21 Jan 2014 22:24:49 +0000 Message-ID: <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> In-Reply-To: <52DEF1ED.8040905@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Olle E Johansson , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:24:53 -0000 No, that implies that 3263 and 6157 are wrong and products that implement n= eed to change - If you want that milestone, first you need to be able be cl= ear about what is wrong with 3263 or 6157. How about=20 > June 2014 Request publication of procedures for dual-stack client and se= rver handling of SIP URIs On Jan 21, 2014, at 3:17 PM, Adam Roach wrote: > It's really quite silly that we're blocked on a trivial matter of termino= logy here. Grabbing my thesaurus, I suggest: >=20 > June 2014 Request publication of procedures to amend RFC3263 > and RFC6157 for dual-stack client and server handling of SIP URIs > containing domain names (PS) >=20 > Does that work for everyone? >=20 > /a >=20 > On 12/18/13 11:12, Paul Kyzivat wrote: >> On 12/17/13 6:54 PM, DRAGE, Keith (Keith) wrote: >>> I said in a previous mail that I would like to avoid the use of the wor= d "supplement" and did suggest alternative wording. My reason is that some = SDOs treat the word "supplement" as identifying informative material, and g= iven that you want reuse in other SDOs it is best not to confuse the issue. >>=20 >> I don't see why that should prevent us from using "supplement" in this c= ontext. We can have that discussion again if the word is used in a draft, b= ut I don't see why it's a concern there either. (The definitive indication = is whether the RFC is standards track, and the normative language in the dr= aft.) >>=20 >>> In any case I don't think we need to bring out in either the title or t= he milestone the exact relationship with RFC 3263, only that one exists. De= fining that relationship more accurately belongs to the abstract. >>=20 >> My latest proposal was: >>=20 >> June 2014 Request publication of procedures to supplement RFC3263 >> and RFC6157 for dual-stack client and server handling of SIP URIs >> containing domain names (PS) >>=20 >> Your earlier proposal was: "Use of RFC 3263 in dual-stack devices". >>=20 >> RFC6157 already addresses dual-stack devices. What we are trying to deal= with is that 3263 and 6157 are insufficient and/or wrong for dual-stack cl= ients. I see no way to avoid using *some* verb - supplement, update, clarif= y, expand, ... >>=20 >> Feel free to offer something that addresses both your concerns and the o= thers that have been raised. >>=20 >> Thanks, >> Paul >>=20 >>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 16 December 2013 20:01 >>>> To: Cullen Jennings (fluffy) >>>> Cc: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith); >>>> SIPCORE WG; Olle E. Johansson >>>> Subject: Re: [sipcore] IPv6 in the sip core wg >>>>=20 >>>> On 12/16/13 2:33 PM, Cullen Jennings (fluffy) wrote: >>>>>=20 >>>>> On Dec 13, 2013, at 9:28 AM, Paul Kyzivat >>>> wrote: >>>>>=20 >>>>>> Having said that, I suggest the following as the milestone: >>>>>>=20 >>>>>> May 2014 WGLC of procedures to supplement RFC3263 for >>>> dual-stack >>>>>> client and server handling of SIP URIs containing domain names >>>>>> (PS) >>>>>=20 >>>>> Good with me. And if you want to change "WGLC of" to >>>> "Request publication of" that seems like it would fix the >>>> point Mary raised. >>>>=20 >>>> OK. Latest candidate is: >>>>=20 >>>> June 2014 Request publication of procedures to >>>> supplement RFC3263 >>>> for dual-stack client and server handling of SIP URIs containing >>>> domain names (PS) >>>>=20 >>>> (I put back the extra month for Mary.) >>>>=20 >>>> Richard - does this work for you? >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From adam@nostrum.com Tue Jan 21 14:40:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3DE1A02D2 for ; Tue, 21 Jan 2014 14:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCF83PMoaBzK for ; Tue, 21 Jan 2014 14:40:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD11A0263 for ; Tue, 21 Jan 2014 14:40:56 -0800 (PST) Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0LMemwK031797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Jan 2014 16:40:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <52DEF76B.9050706@nostrum.com> Date: Tue, 21 Jan 2014 16:40:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> In-Reply-To: <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: Olle E Johansson , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:40:57 -0000 On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: > No, that implies that 3263 and 6157 are wrong and products that implement need to change - If you want that milestone, first you need to be able be clear about what is wrong with 3263 or 6157. How about > >> June 2014 Request publication of procedures for dual-stack client and server handling of SIP URIs That runs the risk of being confused with what 6157 already does. How about: June 2014 Request publication of Happy Eyeballs procedures for handling of SIP URIs Which seems a fair summary of what Olle and Gonzalo's current document intends to do. /a From fluffy@cisco.com Tue Jan 21 14:42:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2D1A0356 for ; Tue, 21 Jan 2014 14:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.036 X-Spam-Level: X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0g2aIvSQb2k for ; Tue, 21 Jan 2014 14:42:58 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 63F781A0263 for ; Tue, 21 Jan 2014 14:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=765; q=dns/txt; s=iport; t=1390344178; x=1391553778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QgCO5jLTLUNNzGqfI0qYaSgzFleMLwnx+nGhJPaXcnQ=; b=TUtjnA0mSgj7ZssgBh+Enmr68eNQdAPEWVVg1GXgl8eNifFEvzpkuyVh b5mpRX4dJL/fnmN/KSbqyPFa5876Bv+3HGPbYAnfgIuxyylGK8a52oi04 wBrHvoRDyCQxkPaGvP2fktb6S3fQdRT6z1/Nw4Cih8+5ftbPEKg9kieKd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFABP33lKtJV2Y/2dsb2JhbABagwuBDrtvgRcWdIIlAQEBAwE6PwULAgEIGB4QMiUCBA4Fh30IwnAXjkwzB4MkgRQBA5gikhiDLYIq X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14496241" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 21 Jan 2014 22:42:58 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMgw22025637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 22:42:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 16:42:57 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHPFvaWweN12un03EeAE6wmKKHd45qPxcQ8gABlLYA= Date: Tue, 21 Jan 2014 22:42:57 +0000 Message-ID: References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> In-Reply-To: <52DEF76B.9050706@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Olle E Johansson , SIPCORE WG , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:42:59 -0000 works for me On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: > On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >> No, that implies that 3263 and 6157 are wrong and products that implemen= t need to change - If you want that milestone, first you need to be able be= clear about what is wrong with 3263 or 6157. How about >>=20 >>> June 2014 Request publication of procedures for dual-stack client and = server handling of SIP URIs >=20 > That runs the risk of being confused with what 6157 already does. How abo= ut: >=20 > June 2014 Request publication of Happy Eyeballs procedures for handling= of SIP URIs >=20 > Which seems a fair summary of what Olle and Gonzalo's current document in= tends to do. >=20 > /a From gsalguei@cisco.com Tue Jan 21 14:44:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CC51A035E for ; Tue, 21 Jan 2014 14:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92mXfssExPQ6 for ; Tue, 21 Jan 2014 14:44:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7DC1A0356 for ; Tue, 21 Jan 2014 14:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1390344283; x=1391553883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2DdZXsvIAeYkqKgr+k0mseE5AiYcwoMEkI4rETHvvvM=; b=C0mVQpoQqmrYxPF9rXIlZwNVut5SgFCjL3gn9QKq5p0UeGp1Kvpkk6Hc Py4WymMMoi5eBaF6Cze2Lj4XqLGJz0xBg8vqIrtR1Ag1gXwOhpDhlqP8F C6TiNQrF2PIqGSvYCEhUdAYR4b7vVsaYm6r2wt96KsiLAoMGgsH/khMfw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAEr33lKtJXG+/2dsb2JhbABaDoJ9gQ67b4EXFnSCJQEBAQMBKRE/EAIBAgYYHhAyJQIEAQ0Fh30IwnAXjkwzB4MkgRQBA5gikhiCbj+CKg X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="298780995" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 21 Jan 2014 22:44:43 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0LMihCF002544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 22:44:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 16:44:43 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Cullen Jennings (fluffy)" , Adam Roach , Paul Kyzivat Thread-Topic: [sipcore] IPv6 in the sip core wg Thread-Index: AQHO92PvPaG9LxtinkCT+HMY0fMEHZpRU8qAgAApEICAADScgIAAAt0AgAAA7wCAAQE5AIAEjfRPgAI4I4CAASIAAIA1xFGAgAACG4CAAARxgIAAAKCAgAAAfQA= Importance: high X-Priority: 1 Date: Tue, 21 Jan 2014 22:44:42 +0000 Message-ID: <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> References: <52A7486E.2090005@alum.mit.edu> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 22:44:45 -0000 +1 -G On Jan 21, 2014, at 5:42 PM, Cullen Jennings (fluffy) wr= ote: >=20 > works for me >=20 > On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: >=20 >> On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >>> No, that implies that 3263 and 6157 are wrong and products that impleme= nt need to change - If you want that milestone, first you need to be able b= e clear about what is wrong with 3263 or 6157. How about >>>=20 >>>> June 2014 Request publication of procedures for dual-stack client and= server handling of SIP URIs >>=20 >> That runs the risk of being confused with what 6157 already does. How ab= out: >>=20 >> June 2014 Request publication of Happy Eyeballs procedures for handling= of SIP URIs >>=20 >> Which seems a fair summary of what Olle and Gonzalo's current document i= ntends to do. >>=20 >> /a >=20 From pkyzivat@alum.mit.edu Tue Jan 21 17:29:38 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01611A0391 for ; Tue, 21 Jan 2014 17:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAiqEWs78_GK for ; Tue, 21 Jan 2014 17:29:37 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5B58B1A0347 for ; Tue, 21 Jan 2014 17:29:37 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id Gp2i1n0020EZKEL53pVc6P; Wed, 22 Jan 2014 01:29:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id GpVb1n00W3ZTu2S3MpVbYn; Wed, 22 Jan 2014 01:29:36 +0000 Message-ID: <52DF1EFF.6080701@alum.mit.edu> Date: Tue, 21 Jan 2014 20:29:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , "Cullen Jennings (fluffy)" , Adam Roach References: <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> In-Reply-To: <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390354176; bh=PbrHYbXulaHakxIhoTakaJYprg+ecKSJBZG5cVKNh/8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NsBqwZnyj/FjX58Fgl2LG/ooVfDMNbuIjOcZY0sUfgicJx8aXKpzKYu7GDthteMSj qyU31TRF6zVUTvA7g1vEnJx+R+X1lEiuj3Kvg67m9Ot1zHTRFu/JuDRDJMMyIu8PIp f/yT6Hbmes8QQ6jCjojklLOpQgnaTb+7X5MWZ31URC7Ot9yh84t7QH3ZKT0HknJUTt r3XFu171nE05xUHehN2DFFWzvI/nXLJ4fD6YmCV9tC7Fw+TDUGUi4BUm+C9MLsal+M cPFPSSII7ZmBPNiKhW+ACD91elNnSg7XVnx3OvsUt7jlcMnZ4puPmMWadCSQjANSca lo5CXTMjvqg5g== Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 01:29:39 -0000 I'm ok with this if it settles the rift. Paul On 1/21/14 5:44 PM, Gonzalo Salgueiro (gsalguei) wrote: > +1 > > -G > > On Jan 21, 2014, at 5:42 PM, Cullen Jennings (fluffy) wrote: > >> >> works for me >> >> On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: >> >>> On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >>>> No, that implies that 3263 and 6157 are wrong and products that implement need to change - If you want that milestone, first you need to be able be clear about what is wrong with 3263 or 6157. How about >>>> >>>>> June 2014 Request publication of procedures for dual-stack client and server handling of SIP URIs >>> >>> That runs the risk of being confused with what 6157 already does. How about: >>> >>> June 2014 Request publication of Happy Eyeballs procedures for handling of SIP URIs >>> >>> Which seems a fair summary of what Olle and Gonzalo's current document intends to do. >>> >>> /a >> > > From oej@edvina.net Tue Jan 21 22:12:15 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAB51A0237 for ; Tue, 21 Jan 2014 22:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MVxlbO6xuOD for ; Tue, 21 Jan 2014 22:12:11 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 081FC1A01AA for ; Tue, 21 Jan 2014 22:12:10 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C073993C2A1; Wed, 22 Jan 2014 06:12:08 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D69EC48-8B7E-4710-87E6-5244554175A5" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: <52DF1EFF.6080701@alum.mit.edu> Date: Wed, 22 Jan 2014 07:12:08 +0100 Message-Id: References: <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> <52DF1EFF.6 080701@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1827) Cc: "Cullen Jennings \(fluffy\)" , SIPCORE WG , Olle E Johansson , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 06:12:15 -0000 --Apple-Mail=_9D69EC48-8B7E-4710-87E6-5244554175A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 22 jan 2014 kl. 02:29 skrev Paul Kyzivat : > I'm ok with this if it settles the rift. >=20 Me too. /O > Paul >=20 > On 1/21/14 5:44 PM, Gonzalo Salgueiro (gsalguei) wrote: >> +1 >>=20 >> -G >>=20 >> On Jan 21, 2014, at 5:42 PM, Cullen Jennings (fluffy) = wrote: >>=20 >>>=20 >>> works for me >>>=20 >>> On Jan 21, 2014, at 3:40 PM, Adam Roach wrote: >>>=20 >>>> On 1/21/14 16:24, Cullen Jennings (fluffy) wrote: >>>>> No, that implies that 3263 and 6157 are wrong and products that = implement need to change - If you want that milestone, first you need to = be able be clear about what is wrong with 3263 or 6157. How about >>>>>=20 >>>>>> June 2014 Request publication of procedures for dual-stack = client and server handling of SIP URIs >>>>=20 >>>> That runs the risk of being confused with what 6157 already does. = How about: >>>>=20 >>>> June 2014 Request publication of Happy Eyeballs procedures for = handling of SIP URIs >>>>=20 >>>> Which seems a fair summary of what Olle and Gonzalo's current = document intends to do. >>>>=20 >>>> /a >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_9D69EC48-8B7E-4710-87E6-5244554175A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
22 jan 2014 kl. 02:29 skrev Paul = Kyzivat <pkyzivat@alum.mit.edu>:
=
I'm ok = with this if it settles the rift.

Me = too.

/O
= Paul

On 1/21/14 5:44 PM, Gonzalo Salgueiro (gsalguei) = wrote:
+1

-G

On Jan 21, 2014, = at 5:42 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> = wrote:


works for me

On Jan = 21, 2014, at 3:40 PM, Adam Roach <adam@nostrum.com> = wrote:

On 1/21/14 16:24, Cullen = Jennings (fluffy) wrote:
No, that implies = that 3263 and 6157 are wrong and products that implement need to change = - If you want that milestone, first you need to be able be clear about = what is wrong with 3263 or 6157.  How about

June 2014  Request publication of procedures for = dual-stack client and server handling of SIP = URIs

That runs the risk of being = confused with what 6157 already does. How about:

 June 2014 = Request publication of Happy Eyeballs procedures for handling of SIP = URIs

Which seems a fair summary of what Olle and Gonzalo's = current document intends to = do.

/a




__= _____________________________________________
sipcore mailing = list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_9D69EC48-8B7E-4710-87E6-5244554175A5-- From vkg@bell-labs.com Wed Jan 22 07:41:45 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB65D1A00EC for ; Wed, 22 Jan 2014 07:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnjNy--2HhuE for ; Wed, 22 Jan 2014 07:41:43 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BFC971A00CF for ; Wed, 22 Jan 2014 07:41:43 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s0MFf4dS000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2014 09:41:05 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s0MFf46M007545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 09:41:04 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s0MFese9000677; Wed, 22 Jan 2014 09:40:55 -0600 (CST) Message-ID: <52DFE6B8.3010903@bell-labs.com> Date: Wed, 22 Jan 2014 09:41:44 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" , "Cullen Jennings (fluffy)" , Adam Roach References: <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> <52DF1EFF.6080701@alum.mit.edu> In-Reply-To: <52DF1EFF.6080701@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: SIPCORE WG , Olle E Johansson Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:41:46 -0000 On 01/21/2014 07:29 PM, Paul Kyzivat wrote: > I'm ok with this if it settles the rift. I liked Paul's original text better, and I suspected that there was some consensus to it, no? In any case, it is not worth having another debate that holds up progress. Whether or not draft-johansson-sip-dual-stack updates only rfc3263 or updates both rfc3253 and rfc6157 can be determined as the work progresses. As such, if folks are happy with "Request publication of Happy Eyeballs procedures for handling of SIP URIs" then lets proceed. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From worley@shell01.TheWorld.com Wed Jan 22 18:31:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF711A038D for ; Wed, 22 Jan 2014 18:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9AIws-dE3RQ for ; Wed, 22 Jan 2014 18:31:05 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 408501A0365 for ; Wed, 22 Jan 2014 18:31:04 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0N2U3HV008604; Wed, 22 Jan 2014 21:30:06 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0N2TieI3388042; Wed, 22 Jan 2014 21:29:44 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0N2ThSo3392497; Wed, 22 Jan 2014 21:29:43 -0500 (EST) Date: Wed, 22 Jan 2014 21:29:43 -0500 (EST) Message-Id: <201401230229.s0N2ThSo3392497@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Vijay K. Gurbani" In-reply-to: <52DFE6B8.3010903@bell-labs.com> (vkg@bell-labs.com) References: <52A8CFC3.3080309@alum.mit.edu> <52A9F990.1030201@alum.mit.edu> <40B29D11-A4EE-4F7B-97C9-612313CFFB7E@cisco.com> <949EF20990823C4C85C18D59AA11AD8B0F858B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0F87DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52AB35A6.8030701@alum.mit.edu> <597D373F-6ACF-4D81-83F0-8CB5A08202E1@cisco.com> <52AF5C0C.9000206@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0FA8CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52B1D794.1080602@alum.mit.edu> <52DEF1ED.8040905@nostrum.com> <2AF35782-4049-4AD6-B1E6-A97171DB94EE@cisco.com> <52DEF76B.9050706@nostrum.com> <35FC50F7-B473-4B2B-8A49-FD23330755D3@cisco.com> <52DF1EFF.6080701@alum.mit.edu> <52DFE6B8.3010903@bell-labs.com> Cc: sipcore@ietf.org Subject: Re: [sipcore] IPv6 in the sip core wg X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 02:31:07 -0000 > From: "Vijay K. Gurbani" > As such, if folks are happy with "Request publication of Happy Eyeballs > procedures for handling of SIP URIs" then lets proceed. Whatever gets the work on the calendar is good. The exact characterization of the output product will only become certain as we complete the work. Dale From brett@broadsoft.com Thu Jan 23 05:10:54 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326281A00A5 for ; Thu, 23 Jan 2014 05:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEJtzAzx-IkF for ; Thu, 23 Jan 2014 05:10:50 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 61F491A03F2 for ; Thu, 23 Jan 2014 05:10:50 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 23 Jan 2014 05:11:16 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 23 Jan 2014 05:11:15 -0800 From: Brett Tate To: Paul Kyzivat , Adam Roach , SIPCORE Thread-Topic: [Technical Errata Reported] RFC3325 (3744) Thread-Index: AQHPEIi5A6HpelC1/kK5tmfOhdX925qSP5mw Date: Thu, 23 Jan 2014 13:11:15 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881AA058E0@MBX08.citservers.local> References: <20131008184950.F23A0B1E013@rfc-editor.org> <576A8B541C219D4E9CEB1DF8C19C7B881A062F18@MBX08.citservers.local> <525569CF.4080709@alum.mit.edu> <9FA07B6E-F3B2-4E3F-B59E-58109B71BD59@amsl.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06EE48@MBX08.citservers.local> <52D4289D.8070903@alum.mit.edu> In-Reply-To: <52D4289D.8070903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] [Technical Errata Reported] RFC3325 (3744) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 13:10:55 -0000 Hi, Concerning the potential extrapolation of the reasoning and resolution to o= ther headers, my current understanding is that an ambiguity must otherwise = exist for ',', ';', or '?' (based upon current draft/RFC) to cause the need= for draft modification or RFC errata to clarify when name-addr must be use= d instead of addr-spec. For instance, the same reasoning and resolution would likely apply to Refer= -To and the other headers mentioned within the following email to avoid amb= iguity related to decoding comma or semicolon. http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html However, P-Charge-Info (draft-york-dispatch-p-charge-info-02) does not have= the same ambiguity concerning comma and semicolon (excluding older drafts = and potential future BNF modifications). And nobody has communicated an am= biguity concerning decoding question mark (although I assume someone had a = reason for including it within the RFC 3261 section 20 bracket rule). Thus= the draft does not need to include a similar statement to clarify when nam= e-addr must be used instead of addr-spec. A device sending P-Charge-Info n= oa based upon draft-york-sipping-p-charge-info-09 without brackets would ca= use a draft-york-dispatch-p-charge-info-02 compliant device to decode the n= oa as a URI parameter (instead of header parameter) since the latest BNF do= es not allow header parameters. Please reply if my understanding of the current reasoning and resolution is= incorrect. Thanks, Brett > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, January 13, 2014 12:56 PM > To: Cullen Jennings (fluffy); Brett Tate > Cc: Alice Russo; Vintaur Chen; Dean Willis; Adam Roach; Jon Peterson; > mwatson@nortelnetworks.com; Keith (Keith) DRAGE; Richard Barnes; > Gonzalo Camarillo; SIPCORE > Subject: Re: [Technical Errata Reported] RFC3325 (3744) >=20 > The chairs have reviewed the discussions regarding this erratum. There > is no ambiguity wrt ";" or "?", but there is wrt ",". So *some* sort of > erratum is in order. The question is what the erratum ought to say. >=20 > It would be "sufficient" to say: >=20 > A P-Asserted-Identity header field value MUST consist of exactly > one > name-addr or addr-spec. If the URI contains a comma the URI MUST > be > enclosed in angle brackets (< and >). >=20 > The erratum currently takes a stronger position: >=20 > A P-Asserted-Identity header field value MUST consist of exactly > one > name-addr or addr-spec. If the URI contains a comma, question mark > or semicolon, the URI MUST be enclosed in angle brackets (< and >). >=20 > The difference is who is at fault if there is a usage that has ";" or > "?" without enclosing <>. >=20 > The chairs agree with the stronger statement, because it is consistent > with the behavior for other similar headers. Without the stronger > statement, implementers that parse these need a special case for this > header. >=20 > I propose that we add an additional note to the erratum: >=20 > 'While the P-Asserted-Identity and P-Preferred-Identity header fields > have an ambiguity only for "," (not for ";" and "?"), we propose that > usage of ";" and "?" also must be inclosed in angle brackets to > preserve > consistency with the RFC 3261 section 20 bracket rule.' >=20 > Anyone who objects to this should speak up now, or we will proceed this > way. >=20 > Thanks, > Paul, as sipcore co-chair >=20 >=20 > On 1/6/14 12:50 PM, Cullen Jennings (fluffy) wrote: > > > > Yep, at this point I think we should leave it up the sip core chars > to make a consensus call on this and then the ADs can decide what to do > and let the RFC Ed know. > > > > > > On Jan 2, 2014, at 12:22 PM, Brett Tate wrote: > > > >> Hi, > >> > >> I sent a reply to sipcore so that maybe consensus can be reached > concerning the topic and errata status adjusted accordingly. > >> > >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05912.html > >> > >> Thanks, > >> Brett > >> > >> From: Alice Russo [mailto:arusso@amsl.com] > >> Sent: Thursday, January 02, 2014 10:36 AM > >> To: Cullen Jennings > >> Cc: Vintaur Chen; Paul Kyzivat; Brett Tate; Dean Willis; Adam Roach; > Jon Peterson; mwatson@nortelnetworks.com; Keith (Keith) DRAGE; Richard > Barnes; Gonzalo Camarillo; RFC Editor > >> Subject: Re: [Technical Errata Reported] RFC3325 (3744) > >> > >> Cullen, > >> > >> Please see the mail below from Vintaur Chen (who is CC'ed) re: > http://www.rfc-editor.org/errata_search.php?rfc=3D3325&eid=3D3744 > >> > >> Also, I've directed Vintaur to the "Bug in RFC 3325" thread on the > sipcore list (approx. starting with http://www.ietf.org/mail- > archive/web/sipcore/current/msg05714.html). > >> > >> Thank you. > >> RFC Editor/ar > >> > >> On Jan 2, 2014, at 9:04 AM, Vintaur Chen wrote: > >> > >> > >> Hi, RFC Editor > >> > >> I disagree with Errata ID: 3744 of RFC 3325, for reasons below. > >> > >> 1. There is no ambiguity in current RFC definition, so the > Errata is unnecessary. > >> The RFC 3261 section 20 rule is involved to avoid the ambiguity > between URI parameters and header parameters. > >> This is not necessary for PAI header, as PAI header has no header > parameters at all. > >> > >> We can make a quick comparing between PAI header and To header here: > >> - PAI header has no pai-param here: > >> PAssertedID =3D "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > >> PAssertedID-value =3D name-addr / addr-spec > >> - Compare this to for example the To-header: > >> To =3D ( "To" / "t" ) HCOLON ( name-addr/ addr-spec ) *( SEMI to- > param ) > >> > >> > >> 2. Errata 3744 is not align with current RFC 3325, so the Errata > is incorrect: > >> > >> Consider the PAI header below: > >> - P-Asserted-Identity: > tel:+98765432109@172.17.151.36;cpc=3Dordinary123 > >> > >> Per current RFC description, the above header is a valid PAI header, > with no ambiguity. > >> Per Errata 3744, the above header is invalid. And Errata 3744 not > descript how to handle such "invalid" header. > >> > >> > >> RFC 3261 section 20 clearly statement that the rule only applicable > for URI in Contact/From/To header. > >> So, it should not be applicable for any other header unless clearly > statement in RFC. > >> The Contact, From, and To header fields contain a URI. If the URI > >> contains a comma, question mark or semicolon, the URI MUST be > >> enclosed in angle brackets (< and >). Any URI parameters are > >> contained within these brackets. If the URI is not enclosed in angle > >> brackets, any semicolon-delimited parameters are header-parameters, > >> not URI parameters. > >> > >> > >> Regards > >> Vintaur Chen > >> > >> > >> On Oct 9, 2013, at 11:48 AM, Cullen Jennings (fluffy) wrote: > >> > >> > >> > >> I started a thead on sip core > >> > >> [...] > >> > >> On Oct 8, 2013, at 12:49 PM, RFC Errata System editor.org> wrote: > >> > >> > >> The following errata report has been submitted for RFC3325, > >> "Private Extensions to the Session Initiation Protocol (SIP) for > Asserted Identity within Trusted Networks". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D3325&eid=3D3744 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Brett Tate > >> > >> Section: 9.1 > >> > >> Original Text > >> ------------- > >> A P-Asserted-Identity header field value MUST consist of exactly one > >> > >> name-addr or addr-spec. > >> > >> Corrected Text > >> -------------- > >> A P-Asserted-Identity header field value MUST consist of exactly one > >> > >> name-addr or addr-spec. If the URI contains a comma, question mark > >> > >> or semicolon, the URI MUST be enclosed in angle brackets (< and >). > >> > >> Notes > >> ----- > >> P-Asserted-Identity ABNF defines PAssertedID-value to be name-addr / > addr-spec. However, no text is added to indicate if the RFC 3261 > section 20 bracket rule fully applies, partially applies, or does not > apply. Some of the confusion is caused by the ABNF not allowing the > header to contain parameters. > >> > >> > >> > >> The same bracket rule should be added to section 9.2 for P- > Preferred-Identity. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or > >> rejected. When a decision is reached, the verifying party (IESG) > >> can log in to change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC3325 (draft-ietf-sip-asserted-identity-01) > >> -------------------------------------- > >> Title : Private Extensions to the Session Initiation > Protocol (SIP) for Asserted Identity within Trusted Networks > >> Publication Date : November 2002 > >> Author(s) : C. Jennings, J. Peterson, M. Watson > >> Category : INFORMATIONAL > >> Source : Session Initiation Protocol > >> Area : Real-time Applications and Infrastructure > >> Stream : IETF > >> Verifying Party : IESG > >> > >> > >> > > > > From pkyzivat@alum.mit.edu Thu Jan 23 09:01:35 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773401A0028 for ; Thu, 23 Jan 2014 09:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpnwt1kqxvCA for ; Thu, 23 Jan 2014 09:01:33 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id B6FAF1A0006 for ; Thu, 23 Jan 2014 09:01:32 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id HRcP1n0071ei1Bg54V1X9N; Thu, 23 Jan 2014 17:01:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id HV1X1n00S3ZTu2S3kV1Xx3; Thu, 23 Jan 2014 17:01:31 +0000 Message-ID: <52E14AEB.4040704@alum.mit.edu> Date: Thu, 23 Jan 2014 12:01:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brett Tate , Adam Roach , SIPCORE References: <20131008184950.F23A0B1E013@rfc-editor.org> <576A8B541C219D4E9CEB1DF8C19C7B881A062F18@MBX08.citservers.local> <525569CF.4080709@alum.mit.edu> <9FA07B6E-F3B2-4E3F-B59E-58109B71BD59@amsl.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06EE48@MBX08.citservers.local> <52D4289D.8070903@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881AA058E0@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881AA058E0@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390496491; bh=ASOUtptyG2F+oYF59iG7MuBboLLJ9xoAv8wfu2mHtrI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VsBJlHuYAGCTvHLubYfSirWJ7ILfR7/wY0xteesVj5aqpM7isDR5Wb080X2gIPAmW zaiPvDe9BUbpB03cHaoI4YXKtdDCT3uzGpuD8mxegNICCh4Ros6OhF2DLFCMadPMdy mDckTgazZXHYPH19DYt7w95+xeI+JaniUwqYi8resLTdsHxCW6iX6dU7oU3FwEHnVV +mx+GeLTrulww+YQFDZPpIRuJM95xaM0cJiAl1vDrNjsBitZ8hdJ7RuBKl59mt/3fX 3sChg8Of7BVQJdxIDn4YoOHkyOJNIJrL8IQlmB3ICEja0RK7B1nIGSnmJ81GyrqyvM Rkoy4IfAAlkxg== Subject: Re: [sipcore] [Technical Errata Reported] RFC3325 (3744) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:01:35 -0000 Brett, What you bring up is an interesting issue. We have lots of headers where the same logic applies. But I see no obvious straightforward way to address them as a group. Certainly to date we have been addressing them one by one. :-( In the 3325 case we decided to include ";" and "?" even though the ambiguity only exists for ",". The reasoning for doing so extends to all similar headers, including those that have no ambiguity for any of these characters. If I had it to do over again I would probably change the ABNF, defining a new symbol: name-addr-spec = name-addr / addr-spec and use that everywhere that (name-addr / addr-spec) is now used. And then I would move the "bracket rule" from section 20, applying it to any use of name-addr-spec. But I don't see a good way to do that without a substantial update to 3261. Thanks, Paul On 1/23/14 8:11 AM, Brett Tate wrote: > Hi, > > Concerning the potential extrapolation of the reasoning and resolution to other headers, my current understanding is that an ambiguity must otherwise exist for ',', ';', or '?' (based upon current draft/RFC) to cause the need for draft modification or RFC errata to clarify when name-addr must be used instead of addr-spec. > > For instance, the same reasoning and resolution would likely apply to Refer-To and the other headers mentioned within the following email to avoid ambiguity related to decoding comma or semicolon. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html > > However, P-Charge-Info (draft-york-dispatch-p-charge-info-02) does not have the same ambiguity concerning comma and semicolon (excluding older drafts and potential future BNF modifications). And nobody has communicated an ambiguity concerning decoding question mark (although I assume someone had a reason for including it within the RFC 3261 section 20 bracket rule). Thus the draft does not need to include a similar statement to clarify when name-addr must be used instead of addr-spec. A device sending P-Charge-Info noa based upon draft-york-sipping-p-charge-info-09 without brackets would cause a draft-york-dispatch-p-charge-info-02 compliant device to decode the noa as a URI parameter (instead of header parameter) since the latest BNF does not allow header parameters. > > Please reply if my understanding of the current reasoning and resolution is incorrect. > > Thanks, > Brett > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, January 13, 2014 12:56 PM >> To: Cullen Jennings (fluffy); Brett Tate >> Cc: Alice Russo; Vintaur Chen; Dean Willis; Adam Roach; Jon Peterson; >> mwatson@nortelnetworks.com; Keith (Keith) DRAGE; Richard Barnes; >> Gonzalo Camarillo; SIPCORE >> Subject: Re: [Technical Errata Reported] RFC3325 (3744) >> >> The chairs have reviewed the discussions regarding this erratum. There >> is no ambiguity wrt ";" or "?", but there is wrt ",". So *some* sort of >> erratum is in order. The question is what the erratum ought to say. >> >> It would be "sufficient" to say: >> >> A P-Asserted-Identity header field value MUST consist of exactly >> one >> name-addr or addr-spec. If the URI contains a comma the URI MUST >> be >> enclosed in angle brackets (< and >). >> >> The erratum currently takes a stronger position: >> >> A P-Asserted-Identity header field value MUST consist of exactly >> one >> name-addr or addr-spec. If the URI contains a comma, question mark >> or semicolon, the URI MUST be enclosed in angle brackets (< and >). >> >> The difference is who is at fault if there is a usage that has ";" or >> "?" without enclosing <>. >> >> The chairs agree with the stronger statement, because it is consistent >> with the behavior for other similar headers. Without the stronger >> statement, implementers that parse these need a special case for this >> header. >> >> I propose that we add an additional note to the erratum: >> >> 'While the P-Asserted-Identity and P-Preferred-Identity header fields >> have an ambiguity only for "," (not for ";" and "?"), we propose that >> usage of ";" and "?" also must be inclosed in angle brackets to >> preserve >> consistency with the RFC 3261 section 20 bracket rule.' >> >> Anyone who objects to this should speak up now, or we will proceed this >> way. >> >> Thanks, >> Paul, as sipcore co-chair >> >> >> On 1/6/14 12:50 PM, Cullen Jennings (fluffy) wrote: >>> >>> Yep, at this point I think we should leave it up the sip core chars >> to make a consensus call on this and then the ADs can decide what to do >> and let the RFC Ed know. >>> >>> >>> On Jan 2, 2014, at 12:22 PM, Brett Tate wrote: >>> >>>> Hi, >>>> >>>> I sent a reply to sipcore so that maybe consensus can be reached >> concerning the topic and errata status adjusted accordingly. >>>> >>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05912.html >>>> >>>> Thanks, >>>> Brett >>>> >>>> From: Alice Russo [mailto:arusso@amsl.com] >>>> Sent: Thursday, January 02, 2014 10:36 AM >>>> To: Cullen Jennings >>>> Cc: Vintaur Chen; Paul Kyzivat; Brett Tate; Dean Willis; Adam Roach; >> Jon Peterson; mwatson@nortelnetworks.com; Keith (Keith) DRAGE; Richard >> Barnes; Gonzalo Camarillo; RFC Editor >>>> Subject: Re: [Technical Errata Reported] RFC3325 (3744) >>>> >>>> Cullen, >>>> >>>> Please see the mail below from Vintaur Chen (who is CC'ed) re: >> http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744 >>>> >>>> Also, I've directed Vintaur to the "Bug in RFC 3325" thread on the >> sipcore list (approx. starting with http://www.ietf.org/mail- >> archive/web/sipcore/current/msg05714.html). >>>> >>>> Thank you. >>>> RFC Editor/ar >>>> >>>> On Jan 2, 2014, at 9:04 AM, Vintaur Chen wrote: >>>> >>>> >>>> Hi, RFC Editor >>>> >>>> I disagree with Errata ID: 3744 of RFC 3325, for reasons below. >>>> >>>> 1. There is no ambiguity in current RFC definition, so the >> Errata is unnecessary. >>>> The RFC 3261 section 20 rule is involved to avoid the ambiguity >> between URI parameters and header parameters. >>>> This is not necessary for PAI header, as PAI header has no header >> parameters at all. >>>> >>>> We can make a quick comparing between PAI header and To header here: >>>> - PAI header has no pai-param here: >>>> PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value >> *(COMMA PAssertedID-value) >>>> PAssertedID-value = name-addr / addr-spec >>>> - Compare this to for example the To-header: >>>> To = ( "To" / "t" ) HCOLON ( name-addr/ addr-spec ) *( SEMI to- >> param ) >>>> >>>> >>>> 2. Errata 3744 is not align with current RFC 3325, so the Errata >> is incorrect: >>>> >>>> Consider the PAI header below: >>>> - P-Asserted-Identity: >> tel:+98765432109@172.17.151.36;cpc=ordinary123 >>>> >>>> Per current RFC description, the above header is a valid PAI header, >> with no ambiguity. >>>> Per Errata 3744, the above header is invalid. And Errata 3744 not >> descript how to handle such "invalid" header. >>>> >>>> >>>> RFC 3261 section 20 clearly statement that the rule only applicable >> for URI in Contact/From/To header. >>>> So, it should not be applicable for any other header unless clearly >> statement in RFC. >>>> The Contact, From, and To header fields contain a URI. If the URI >>>> contains a comma, question mark or semicolon, the URI MUST be >>>> enclosed in angle brackets (< and >). Any URI parameters are >>>> contained within these brackets. If the URI is not enclosed in angle >>>> brackets, any semicolon-delimited parameters are header-parameters, >>>> not URI parameters. >>>> >>>> >>>> Regards >>>> Vintaur Chen >>>> >>>> >>>> On Oct 9, 2013, at 11:48 AM, Cullen Jennings (fluffy) wrote: >>>> >>>> >>>> >>>> I started a thead on sip core >>>> >>>> [...] >>>> >>>> On Oct 8, 2013, at 12:49 PM, RFC Errata System > editor.org> wrote: >>>> >>>> >>>> The following errata report has been submitted for RFC3325, >>>> "Private Extensions to the Session Initiation Protocol (SIP) for >> Asserted Identity within Trusted Networks". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3325&eid=3744 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Brett Tate >>>> >>>> Section: 9.1 >>>> >>>> Original Text >>>> ------------- >>>> A P-Asserted-Identity header field value MUST consist of exactly one >>>> >>>> name-addr or addr-spec. >>>> >>>> Corrected Text >>>> -------------- >>>> A P-Asserted-Identity header field value MUST consist of exactly one >>>> >>>> name-addr or addr-spec. If the URI contains a comma, question mark >>>> >>>> or semicolon, the URI MUST be enclosed in angle brackets (< and >). >>>> >>>> Notes >>>> ----- >>>> P-Asserted-Identity ABNF defines PAssertedID-value to be name-addr / >> addr-spec. However, no text is added to indicate if the RFC 3261 >> section 20 bracket rule fully applies, partially applies, or does not >> apply. Some of the confusion is caused by the ABNF not allowing the >> header to contain parameters. >>>> >>>> >>>> >>>> The same bracket rule should be added to section 9.2 for P- >> Preferred-Identity. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party (IESG) >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3325 (draft-ietf-sip-asserted-identity-01) >>>> -------------------------------------- >>>> Title : Private Extensions to the Session Initiation >> Protocol (SIP) for Asserted Identity within Trusted Networks >>>> Publication Date : November 2002 >>>> Author(s) : C. Jennings, J. Peterson, M. Watson >>>> Category : INFORMATIONAL >>>> Source : Session Initiation Protocol >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>>> >>>> >>> >>> > > From worley@shell01.TheWorld.com Thu Jan 23 14:46:04 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682101A047A for ; Thu, 23 Jan 2014 14:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpe_gvG68Bpf for ; Thu, 23 Jan 2014 14:46:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E32221A0476 for ; Thu, 23 Jan 2014 14:46:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0NMjl9D032207 for ; Thu, 23 Jan 2014 17:45:49 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0NMjlpa3450102 for ; Thu, 23 Jan 2014 17:45:47 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0NMjlFb3432945; Thu, 23 Jan 2014 17:45:47 -0500 (EST) Date: Thu, 23 Jan 2014 17:45:47 -0500 (EST) Message-Id: <201401232245.s0NMjlFb3432945@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] The versions of SIP digest authentication X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:46:04 -0000 I accumulated the information I could find regarding the three (!) versions of SIP digest authentication that have been defined. The following chart summarizes the relationship between these various documents. In particular, beware that RFC 2543's version is based on RFC 2617, but RFC 3261 incorrectly states that RFC 2453 is based on RFC 2069. In principle, I'd like to see this documented in draft-ietf-sipcore-digest-scheme, but I'm not sure that it would be worth the effort. SIP auth. Based on HTTP auth. Changes from previous version --------- ------------------- ----------------------------- RFC 2543 RFC 2617[1] -- RFC 3261 RFC 2617 Basic auth. forbidden draft-ietf- draft-ietf- added SHA2-256, SHA2-256-sess, sipcore-digest-scheme httpauth-digest SHA2-512-256, and SHA2-512-256-sess "qop" is required [1] RFC 3261 states in section 22.4 that "RFC 2543 is based on HTTP Digest as defined in RFC 2069", however this is incorrect. The reference in RFC 2543 is to "HTTP authentication: Basic and digest access authentication," Internet Draft, Sept. 1998, which resolves to draft-ietf-http-authentication-03, which is the last draft version of RFC 2617. But RFC 2617 does describe mechanisms to provide backward compatibility with RFC 2069, and it appears from RFC 3261, section 22.4, item 8 that some pre-2543 implementations only supported 2069 authentication. Dale From worley@shell01.TheWorld.com Thu Jan 23 14:49:15 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7BE1A0476 for ; Thu, 23 Jan 2014 14:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpclQMBsBRux for ; Thu, 23 Jan 2014 14:49:13 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76C1A00C9 for ; Thu, 23 Jan 2014 14:49:13 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0NMmJPn018623 for ; Thu, 23 Jan 2014 17:48:21 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0NMmJVB3445325 for ; Thu, 23 Jan 2014 17:48:19 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0NMmJkZ3445035; Thu, 23 Jan 2014 17:48:19 -0500 (EST) Date: Thu, 23 Jan 2014 17:48:19 -0500 (EST) Message-Id: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:49:15 -0000 Here are some comments on draft-yusef-sipcore-digest-scheme-03: Section 2 says, "This section describes the modifications to the operation of the Digest mechanism as specified in RFC3261." I think it would be helpful here to also point to HTTP-DIGEST by adding "... in order to support the SHA2-256 and SHA2-512/256 algorithms as described in [HTTP-DIGEST], and also to require support for the "qop" option." The text is a bit hazy about the distinction between the *name* of the algorithm and the "algorithm" value that is used to specify the algorithm. In particular, one algorithm is *called* "SHA2-512/256", but its corresponding *value* is "SHA2-512-256". This is easy enough to understand, but it may be inviting trouble. It appears that the underlying problem is that "/" is not a token character, and that RFC 3261 restricts algorithm values to being tokens. Two algorithms are called "SHA2-256" and "SHA2-512/256". But the standard names for these two algorithms seem to be "SHA-256" and "SHA-512/256", looking at the Wikipedia page "SHA-2" and mentions of these algorithms in the titles of various RFCs. The use of "-sess" seems to be poorly specified. Much of the text treats algorithm values ending in "-sess" opaquely, in that certain enumerated algorithm values that happen to end in "-sess" cause the A1 processing to be modified. But the intention seems to be that "-sess" is a *modifier* of an algorithm that is otherwise defined. It seems like there should be a specification of the meaning of "-sess" that is orthogonal to the algorithm name proper. Section 2.3 says, "If the UAS challenges with multiple WWW-Authenticate/Proxy- Authenticate headers, then each one of these headers MUST use a different digest algorithm." We don't want this restriction because it would forbid the UAS to provide multiple challenges with different realms but the same algorithm. In addition, this restriction provides no benefit to UACs, because when a proxy aggregates challenges, even if the UASs are following this rule, the aggregated challenge may not follow this rule. Section 2.3 says, "The UAS MUST add these headers to the response in order of strength of the algorithm, starting with the strongest algorithm, followed by the less strong algorithms." I think the rule you want is that the challenges should be listed in the order that the UAS would prefer to see them used. In general, this SHOULD be in order of cryptographic strength, but there could be other considerations, and it's possible that the consensus of cryptographic strength could change over time, leaving an implementation out-of-compliance. Section 2.4 says, "If the UAC does not support any of the algorithms in the response, then it should abandon attempts to send the request." I think this can be generalized to "If the UAC cannot respond to any of the challenges in the response ..."; e.g., if the UAC does not have credentials for any of the realms. Section 2.5 says, "When the forking proxy places multiple WWW-Authenticate and Proxy-Authenticate header fields from one proxy into the single response it MUST maintain the order of these header fields. The ordering of the header field values from the various proxies is not significant." I think "one proxy" should be "one received response". In theory, it may not be possible for the proxy to both remove all duplicates from the list and also maintain the order from each received response (since two duplicated headers might appear in opposite orders in two responses). But I think that is impossible unless two received responses can have headers with the same nonce value. Section 2.6 says, "The SIP scheme usage is almost completely identical to that for HTTP." I'd prefer "... is similar to that for HTTP." given that the differences are quite significant (especially in that the request URI is not protected). Section 2.6 says, "This section does NOT maintain backward compatibility with RFC 2543." This statement needs to be fleshed out. In one sense, it is not backward compatible with *RFC 3261*, because it requires UAs to fully support "qop" -- UAs that are compliant with RFC 3261 but don't support "qop" are not compliant with the modified RFC 3261. On the other hand, as long as UAs can deal with their other-ends not supporting "qop" (which I expect to be the universal implementation practice), then they are *compatible* with such UAs. There is also the problem that "compatibility with RFC 2543" is used to mean "compatibility with RFC 2069 (which was referenced in early drafts of RFC 2543)". I'm not sure if that's technically incorrect, but it would probably be clearer to state "RFC 2069" directly. Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache operation does not apply to SIP." There are some tricky issues surrounding the binding-time of the reference "[17]". For clarity, this probably needs to be turned into a reference that is resolved within this document. And a comment about draft-ietf-httpauth-digest-04: This draft creates a registry named "HTTP Digest Hash Algorithms". There is already a registry named "HTTP Digest Algorithm Values" (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml). That latter registry has a different purpose, similar algorithm names, and specifies that the algorithm outputs are to be presented in base64. I think there is a significant danger of confusion, but it would also be difficult to combine them. Dale From rifaat.ietf@gmail.com Thu Jan 23 17:27:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A31A017D for ; Thu, 23 Jan 2014 17:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdmlxj8U_7RL for ; Thu, 23 Jan 2014 17:27:04 -0800 (PST) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64A1A024A for ; Thu, 23 Jan 2014 17:27:03 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b57so678929eek.24 for ; Thu, 23 Jan 2014 17:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PR4uYCjswGiCKU/muFC8TjYKuYnKLIDmX091t1wh8PQ=; b=by0Agt+Ubb7Ve1UHrVURCH6xRS0vvexHv9uZN8/JIzAUwJT/2rGFNfFW0IEUVloLN/ v3yt6rjoZknLGbjS1IbsMszfFFOnWk3+g8yZ7s+mmeVrBzILVU7QaEP7w2iqB9tvy1l4 Pcv04juNFjKYNAYIM2MsdwzP4O6ZM8cYdKHbjIJaLaXK1Z56jU9PzhP4ySao9pILEerp TDOvBSX9Jr/DOWvnHv8xxyBNWeOBTACs35QkWLiCOcmVgWauuPYO97Xc4KSEy2GCcXue gnWNVHBlc7xV2YjRhL9Yvo/eM0sf4Hca62qT0xGFBaWO2PnNS7XOC++LNsBt6OJjwW1A QTYQ== MIME-Version: 1.0 X-Received: by 10.14.172.69 with SMTP id s45mr9937065eel.9.1390526822577; Thu, 23 Jan 2014 17:27:02 -0800 (PST) Received: by 10.14.53.78 with HTTP; Thu, 23 Jan 2014 17:27:02 -0800 (PST) In-Reply-To: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> Date: Thu, 23 Jan 2014 20:27:02 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c395364f78c504f0ad41a2 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 01:27:09 -0000 --001a11c395364f78c504f0ad41a2 Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Thanks a lot for these great comments. See my reply inline... Regards, Rifaat On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley wrote: > Here are some comments on draft-yusef-sipcore-digest-scheme-03: > > Section 2 says, "This section describes the modifications to the > operation of the Digest mechanism as specified in RFC3261." > > I think it would be helpful here to also point to HTTP-DIGEST by > adding "... in order to support the SHA2-256 and SHA2-512/256 > algorithms as described in [HTTP-DIGEST], and also to require support > for the "qop" option." > > Ok > The text is a bit hazy about the distinction between the *name* of the > algorithm and the "algorithm" value that is used to specify the > algorithm. In particular, one algorithm is *called* "SHA2-512/256", > but its corresponding *value* is "SHA2-512-256". This is easy enough > to understand, but it may be inviting trouble. It appears that the > underlying problem is that "/" is not a token character, and that RFC > 3261 restricts algorithm values to being tokens. > > How do you suggest I fix that? > Two algorithms are called "SHA2-256" and "SHA2-512/256". But the > standard names for these two algorithms seem to be "SHA-256" and > "SHA-512/256", looking at the Wikipedia page "SHA-2" and mentions of > these algorithms in the titles of various RFCs. > > Ok, I will change the name to align with the standard name. > The use of "-sess" seems to be poorly specified. Much of the text > treats algorithm values ending in "-sess" opaquely, in that certain > enumerated algorithm values that happen to end in "-sess" cause the A1 > processing to be modified. But the intention seems to be that "-sess" > is a *modifier* of an algorithm that is otherwise defined. It seems > like there should be a specification of the meaning of "-sess" that is > orthogonal to the algorithm name proper. > I need to think about this one. > Section 2.3 says, "If the UAS challenges with multiple > WWW-Authenticate/Proxy- Authenticate headers, then each one of these > headers MUST use a different digest algorithm." > > We don't want this restriction because it would forbid the UAS to > provide multiple challenges with different realms but the same > algorithm. In addition, this restriction provides no benefit to UACs, > because when a proxy aggregates challenges, even if the UASs are > following this rule, the aggregated challenge may not follow this > rule. > > I will clarify it to make it clear that this limitation is for multiple headers with the same realm. > Section 2.3 says, "The UAS MUST add these headers to the response in > order of strength of the algorithm, starting with the strongest > algorithm, followed by the less strong algorithms." > > I think the rule you want is that the challenges should be listed in > the order that the UAS would prefer to see them used. In general, > this SHOULD be in order of cryptographic strength, but there could be > other considerations, and it's possible that the consensus of > cryptographic strength could change over time, leaving an > implementation out-of-compliance. > > Good point. I will fix it. > Section 2.4 says, "If the UAC does not support any of the algorithms > in the response, then it should abandon attempts to send the request." > > I think this can be generalized to "If the UAC cannot respond to any > of the challenges in the response ..."; e.g., if the UAC does not have > credentials for any of the realms. > > Ok > Section 2.5 says, "When the forking proxy places multiple > WWW-Authenticate and Proxy-Authenticate header fields from one proxy > into the single response it MUST maintain the order of these header > fields. The ordering of the header field values from the various > proxies is not significant." > > I think "one proxy" should be "one received response". > > Ok. > In theory, it may not be possible for the proxy to both remove all > duplicates from the list and also maintain the order from each > received response (since two duplicated headers might appear in > opposite orders in two responses). But I think that is impossible > unless two received responses can have headers with the same nonce > value. > > Section 2.6 says, "The SIP scheme usage is almost completely identical > to that for HTTP." > > I'd prefer "... is similar to that for HTTP." given that the > differences are quite significant (especially in that the request URI > is not protected). > > Ok. > Section 2.6 says, "This section does NOT maintain backward > compatibility with RFC 2543." > > This statement needs to be fleshed out. In one sense, it is not > backward compatible with *RFC 3261*, because it requires UAs to fully > support "qop" -- UAs that are compliant with RFC 3261 but don't > support "qop" are not compliant with the modified RFC 3261. > > On the other hand, as long as UAs can deal with their other-ends not > supporting "qop" (which I expect to be the universal implementation > practice), then they are *compatible* with such UAs. > > There is also the problem that "compatibility with RFC 2543" is used > to mean "compatibility with RFC 2069 (which was referenced in early > drafts of RFC 2543)". I'm not sure if that's technically incorrect, > but it would probably be clearer to state "RFC 2069" directly. > > How about replacing the MUST with SHOULD in section 2.6, bullet 7, as follows: Servers SHOULD be able to properly handle "qop" parameter received in an authorization header field, and clients SHOULD be able to properly handle "qop" parameter received in WWW-Authenticate and Proxy-Authenticate header fields. Servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values, and clients MUST send the "qop" parameter in any resulting authorization header field. > Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache > operation does not apply to SIP." > > There are some tricky issues surrounding the binding-time of the > reference "[17]". For clarity, this probably needs to be turned into > a reference that is resolved within this document. > > Yes. > And a comment about draft-ietf-httpauth-digest-04: > > This draft creates a registry named "HTTP Digest Hash Algorithms". > There is already a registry named "HTTP Digest Algorithm Values" > (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml). > That latter registry has a different purpose, similar algorithm names, > and specifies that the algorithm outputs are to be presented in > base64. I think there is a significant danger of confusion, but it > would also be difficult to combine them. > > Yeah, it might confuse people. Do you have a better name for this registry? Regards, Rifaat Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c395364f78c504f0ad41a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks a lot for these great c= omments.
See my reply inline...

Regards,=
=A0Rifaat


On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley <worley@ariadne.com&g= t; wrote:
Here are some comments on draft-yusef-sipcore-digest-scheme-03:

Section 2 says, "This section describes the modifications to the
operation of the Digest mechanism as specified in RFC3261."

I think it would be helpful here to also point to HTTP-DIGEST by
adding "... in order to support the SHA2-256 and SHA2-512/256
algorithms as described in [HTTP-DIGEST], and also to require support
for the "qop" option."


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> The text is a bit hazy about the distinction between the *name* of the
algorithm and the "algorithm" value that is used to specify the algorithm. =A0In particular, one algorithm is *called* "SHA2-512/256&q= uot;,
but its corresponding *value* is "SHA2-512-256". =A0This is easy = enough
to understand, but it may be inviting trouble. =A0It appears that the
underlying problem is that "/" is not a token character, and that= RFC
3261 restricts algorithm values to being tokens.


How do you suggest I fix that?

=A0
Two algorithms are called "SHA2-256" and "SHA2-512/256"= . =A0But the
standard names for these two algorithms seem to be =A0"SHA-256" a= nd
"SHA-512/256", looking at the Wikipedia page "SHA-2" an= d mentions of
these algorithms in the titles of various RFCs.


Ok, I will change the name to align wi= th the standard name.

=A0
The use of "-sess" seems to be poorly specified. =A0Much of the t= ext
treats algorithm values ending in "-sess" opaquely, in that certa= in
enumerated algorithm values that happen to end in "-sess" cause t= he A1
processing to be modified. =A0But the intention seems to be that "-ses= s"
is a *modifier* of an algorithm that is otherwise defined. =A0It seems
like there should be a specification of the meaning of "-sess" th= at is
orthogonal to the algorithm name proper.

I need to think about this one.

=A0
Section 2.3 says, "If the UAS challenges with multiple
WWW-Authenticate/Proxy- Authenticate headers, then each one of these
headers MUST use a different digest algorithm."

We don't want this restriction because it would forbid the UAS to
provide multiple challenges with different realms but the same
algorithm. =A0In addition, this restriction provides no benefit to UACs, because when a proxy aggregates challenges, even if the UASs are
following this rule, the aggregated challenge may not follow this
rule.


I will clarify it to make it clear tha= t this limitation is for multiple headers with the same realm.
=A0
Section 2.3 says, "The UAS MUST add these headers to the response in order of strength of the algorithm, starting with the strongest
algorithm, followed by the less strong algorithms."

I think the rule you want is that the challenges should be listed in
the order that the UAS would prefer to see them used. =A0In general,
this SHOULD be in order of cryptographic strength, but there could be
other considerations, and it's possible that the consensus of
cryptographic strength could change over time, leaving an
implementation out-of-compliance.


Good point. I will fix it.
<= br>
=A0
Section 2.4 says, "If the UAC does not support any of the algorithms in the response, then it should abandon attempts to send the request."=

I think this can be generalized to "If the UAC cannot respond to any of the challenges in the response ..."; e.g., if the UAC does not have=
credentials for any of the realms.


Ok

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Section 2.5 says, "When the forking proxy places multiple
WWW-Authenticate and Proxy-Authenticate header fields from one proxy
into the single response it MUST maintain the order of these header
fields. The ordering of the header field values from the various
proxies is not significant."

I think "one proxy" should be "one received response".<= br>

Ok.


=A0
In theory, it may not be possible for the proxy to both remove all
duplicates from the list and also maintain the order from each
received response (since two duplicated headers might appear in
opposite orders in two responses). =A0But I think that is impossible
unless two received responses can have headers with the same nonce
value.

Section 2.6 says, "The SIP scheme usage is almost completely identical=
to that for HTTP."

I'd prefer "... is similar to that for HTTP." given that the<= br> differences are quite significant (especially in that the request URI
is not protected).


Ok.

=A0
=
Section 2.6 says, "This section does NOT maintain backward
compatibility with RFC 2543."

This statement needs to be fleshed out. =A0In one sense, it is not
backward compatible with *RFC 3261*, because it requires UAs to fully
support "qop" -- UAs that are compliant with RFC 3261 but don'= ;t
support "qop" are not compliant with the modified RFC 3261.

On the other hand, as long as UAs can deal with their other-ends not
supporting "qop" (which I expect to be the universal implementati= on
practice), then they are *compatible* with such UAs.

There is also the problem that "compatibility with RFC 2543" is u= sed
to mean "compatibility with RFC 2069 (which was referenced in early drafts of RFC 2543)". =A0I'm not sure if that's technically in= correct,
but it would probably be clearer to state "RFC 2069" directly.

How about replacing the MUST with SHOU= LD in section 2.6, bullet 7, as follows:

=A0 = =A0Servers SHOULD be able to properly handle "qop" parameter rece= ived
=A0 =A0in an authorization header field, and clients SHOULD be able to= =A0
=A0 =A0properly handle "qop" parameter received in = WWW-Authenticate and=A0
=A0 =A0Proxy-Authenticate header fields.<= /div>

=A0 =A0Servers MUST always send a "qop" parameter in W= WW-Authenticate=A0
=A0 =A0and Proxy-Authenticate header field val= ues, and clients MUST=A0
=A0 =A0send the "qop" paramete= r in any resulting authorization header=A0
=A0 =A0field.


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache
operation does not apply to SIP."

There are some tricky issues surrounding the binding-time of the
reference "[17]". =A0For clarity, this probably needs to be turne= d into
a reference that is resolved within this document.


Yes.

=A0
And a comment about draft-ietf-httpauth-digest-04:

This draft creates a registry named "HTTP Digest Hash Algorithms"= .
There is already a registry named "HTTP Digest Algorithm Values"<= br> (http://www.iana.org/assignments/http-dig-alg/http-dig-a= lg.xhtml).
That latter registry has a different purpose, similar algorithm names,
and specifies that the algorithm outputs are to be presented in
base64. =A0I think there is a significant danger of confusion, but it
would also be difficult to combine them.


Yeah, it might confuse people. Do you = have a better name for this registry?

=A0
Regards,
=A0Rifaat


Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a11c395364f78c504f0ad41a2-- From pkyzivat@alum.mit.edu Thu Jan 23 19:24:34 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C0B1A0098 for ; Thu, 23 Jan 2014 19:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apEC0UUYitkO for ; Thu, 23 Jan 2014 19:24:32 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8D1A00A1 for ; Thu, 23 Jan 2014 19:24:32 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id HfL81n0020QuhwU5AfQWb8; Fri, 24 Jan 2014 03:24:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id HfQW1n00E3ZTu2S3NfQWte; Fri, 24 Jan 2014 03:24:30 +0000 Message-ID: <52E1DCEE.4020007@alum.mit.edu> Date: Thu, 23 Jan 2014 22:24:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390533870; bh=aMQEPpanvz/JbsgQh6GlegEiWNMlglbMLLBk/ZaRvZU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VS+qnio4K5kZP0QZcGl1KA1Cb2nHce6qOvhpUjY/NSalNYMMJYp0IB9trbYnRxQUr 0Un4Zi3PG4815/wskKmdB3fDsvzjAcor4w/SxkHtauEMu7dGV/IYVJM6VgATPgrG76 Q3udlmK3mk8a3CxolG+dXVFuXlQo4hgMAQ6gGURHXUxElvAn/sreDe4ut9P+lmo/jY QQABWCFw7Rao3IsfOo32RrwjdqhjAvu19ck3ZEllkK0Qkyaw52x8c9ZBYPxU4lyDr3 JKF+rOjpPEe95mr1/FyuYBSKP9Dg4zr2sEblocdYfpXSsr3+By9CXyxksNoqVLowov tyS6memTrv5zw== Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 03:24:34 -0000 I have added a few comments inline. Thanks, Paul On 1/23/14 8:27 PM, Rifaat Shekh-Yusef wrote: > Hi Dale, > > Thanks a lot for these great comments. > See my reply inline... > > Regards, > Rifaat > > > > On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley > wrote: > > Here are some comments on draft-yusef-sipcore-digest-scheme-03: > > Section 2 says, "This section describes the modifications to the > operation of the Digest mechanism as specified in RFC3261." > > I think it would be helpful here to also point to HTTP-DIGEST by > adding "... in order to support the SHA2-256 and SHA2-512/256 > algorithms as described in [HTTP-DIGEST], and also to require support > for the "qop" option." > > > Ok > > The text is a bit hazy about the distinction between the *name* of the > algorithm and the "algorithm" value that is used to specify the > algorithm. In particular, one algorithm is *called* "SHA2-512/256", > but its corresponding *value* is "SHA2-512-256". This is easy enough > to understand, but it may be inviting trouble. It appears that the > underlying problem is that "/" is not a token character, and that RFC > 3261 restricts algorithm values to being tokens. > > > How do you suggest I fix that? > > > Two algorithms are called "SHA2-256" and "SHA2-512/256". But the > standard names for these two algorithms seem to be "SHA-256" and > "SHA-512/256", looking at the Wikipedia page "SHA-2" and mentions of > these algorithms in the titles of various RFCs. > > > Ok, I will change the name to align with the standard name. > > The use of "-sess" seems to be poorly specified. Much of the text > treats algorithm values ending in "-sess" opaquely, in that certain > enumerated algorithm values that happen to end in "-sess" cause the A1 > processing to be modified. But the intention seems to be that "-sess" > is a *modifier* of an algorithm that is otherwise defined. It seems > like there should be a specification of the meaning of "-sess" that is > orthogonal to the algorithm name proper. > > > I need to think about this one. I've been trying to get at this too. It is really a defect in the original definition of digest, but it is how hard to get out of. Till now my suggestion has been that it is just up to each new algorithm to specify a -sess variant if appropriate, and to define it. If it will always be the case that every new algorithm should have a -sess variant and a non-sess variant, and that the difference between them can be defined once, then it would be better to do that, and change the syntax to just in clude a [ "-sess" ] and a common definition of what that means. > Section 2.3 says, "If the UAS challenges with multiple > WWW-Authenticate/Proxy- Authenticate headers, then each one of these > headers MUST use a different digest algorithm." > > We don't want this restriction because it would forbid the UAS to > provide multiple challenges with different realms but the same > algorithm. In addition, this restriction provides no benefit to UACs, > because when a proxy aggregates challenges, even if the UASs are > following this rule, the aggregated challenge may not follow this > rule. > > > I will clarify it to make it clear that this limitation is for multiple > headers with the same realm. > > Section 2.3 says, "The UAS MUST add these headers to the response in > order of strength of the algorithm, starting with the strongest > algorithm, followed by the less strong algorithms." > > I think the rule you want is that the challenges should be listed in > the order that the UAS would prefer to see them used. In general, > this SHOULD be in order of cryptographic strength, but there could be > other considerations, and it's possible that the consensus of > cryptographic strength could change over time, leaving an > implementation out-of-compliance. > > > Good point. I will fix it. > > Section 2.4 says, "If the UAC does not support any of the algorithms > in the response, then it should abandon attempts to send the request." > > I think this can be generalized to "If the UAC cannot respond to any > of the challenges in the response ..."; e.g., if the UAC does not have > credentials for any of the realms. > > > Ok I think that is too strong. Suppose the request has been forked, with separate challenges from each fork, and the proxy has merged them. If the UAC can only respond to one of the challenges, that should be ok. Then one fork will work and the other will not. > Section 2.5 says, "When the forking proxy places multiple > WWW-Authenticate and Proxy-Authenticate header fields from one proxy > into the single response it MUST maintain the order of these header > fields. The ordering of the header field values from the various > proxies is not significant." > > I think "one proxy" should be "one received response". > > > Ok. > > > In theory, it may not be possible for the proxy to both remove all > duplicates from the list and also maintain the order from each > received response (since two duplicated headers might appear in > opposite orders in two responses). But I think that is impossible > unless two received responses can have headers with the same nonce > value. > > Section 2.6 says, "The SIP scheme usage is almost completely identical > to that for HTTP." > > I'd prefer "... is similar to that for HTTP." given that the > differences are quite significant (especially in that the request URI > is not protected). > > > Ok. > > Section 2.6 says, "This section does NOT maintain backward > compatibility with RFC 2543." > > This statement needs to be fleshed out. In one sense, it is not > backward compatible with *RFC 3261*, because it requires UAs to fully > support "qop" -- UAs that are compliant with RFC 3261 but don't > support "qop" are not compliant with the modified RFC 3261. > > On the other hand, as long as UAs can deal with their other-ends not > supporting "qop" (which I expect to be the universal implementation > practice), then they are *compatible* with such UAs. > > There is also the problem that "compatibility with RFC 2543" is used > to mean "compatibility with RFC 2069 (which was referenced in early > drafts of RFC 2543)". I'm not sure if that's technically incorrect, > but it would probably be clearer to state "RFC 2069" directly. > > > How about replacing the MUST with SHOULD in section 2.6, bullet 7, as > follows: > > Servers SHOULD be able to properly handle "qop" parameter received > in an authorization header field, and clients SHOULD be able to > properly handle "qop" parameter received in WWW-Authenticate and > Proxy-Authenticate header fields. > > Servers MUST always send a "qop" parameter in WWW-Authenticate > and Proxy-Authenticate header field values, and clients MUST > send the "qop" parameter in any resulting authorization header > field. > > > Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache > operation does not apply to SIP." > > There are some tricky issues surrounding the binding-time of the > reference "[17]". For clarity, this probably needs to be turned into > a reference that is resolved within this document. > > > Yes. > > And a comment about draft-ietf-httpauth-digest-04: > > This draft creates a registry named "HTTP Digest Hash Algorithms". > There is already a registry named "HTTP Digest Algorithm Values" > (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml). > That latter registry has a different purpose, similar algorithm names, > and specifies that the algorithm outputs are to be presented in > base64. I think there is a significant danger of confusion, but it > would also be difficult to combine them. > > > Yeah, it might confuse people. Do you have a better name for this registry? > > Regards, > Rifaat > > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Fri Jan 24 05:38:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0E1A0372 for ; Fri, 24 Jan 2014 05:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbxqbHqvveCD for ; Fri, 24 Jan 2014 05:38:41 -0800 (PST) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 52A911A035F for ; Fri, 24 Jan 2014 05:38:41 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id o10so440752eaj.25 for ; Fri, 24 Jan 2014 05:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zsdV00kfkVJ81CpkPplSkn0w7He9NX0VqUEHSl8QpIo=; b=IVWmr0OqOoxuXGSpbtXap0gRvpFRqzmE02COs2NV537BMK2zyvz1Fr0rYrKAsDU/6r oU9FIrPF4B/6c0HzK0MdRdOEUBTKNxNnnHK1QWVTdey+SA8qRZTLODiKuoUROQh2NKHg TaYw2nSyEAv+r9jyWIIfHcZ8SMYSIHuWwwnEDGQALyOk4GZfDG4WlZmsD+ESru7QIwWe 16FGdKNNdR2OjOlQ1Va6wPNA+eV8xvJ5uOyAaZ6+VX9A6mn3rJ1idQJjx6LbQua/qZp3 tGcJksATUZjq4Alp3soLseVMIfIMl6/D7LmyYevJ8LFsUjjFwefQ/e7RCrTyfwPl+Hiu EBvA== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr8801824eew.61.1390570719499; Fri, 24 Jan 2014 05:38:39 -0800 (PST) Received: by 10.14.53.78 with HTTP; Fri, 24 Jan 2014 05:38:39 -0800 (PST) In-Reply-To: <52E1DCEE.4020007@alum.mit.edu> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> Date: Fri, 24 Jan 2014 08:38:39 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c3fb70c55b1804f0b77979 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 13:38:44 -0000 --001a11c3fb70c55b1804f0b77979 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Thu, Jan 23, 2014 at 10:24 PM, Paul Kyzivat wrote: > I have added a few comments inline. > > Thanks, > Paul > > > On 1/23/14 8:27 PM, Rifaat Shekh-Yusef wrote: > >> Hi Dale, >> >> Thanks a lot for these great comments. >> See my reply inline... >> >> Regards, >> Rifaat >> >> >> >> On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley > > wrote: >> >> Here are some comments on draft-yusef-sipcore-digest-scheme-03: >> >> Section 2 says, "This section describes the modifications to the >> operation of the Digest mechanism as specified in RFC3261." >> >> I think it would be helpful here to also point to HTTP-DIGEST by >> adding "... in order to support the SHA2-256 and SHA2-512/256 >> algorithms as described in [HTTP-DIGEST], and also to require support >> for the "qop" option." >> >> >> Ok >> >> The text is a bit hazy about the distinction between the *name* of the >> algorithm and the "algorithm" value that is used to specify the >> algorithm. In particular, one algorithm is *called* "SHA2-512/256", >> but its corresponding *value* is "SHA2-512-256". This is easy enough >> to understand, but it may be inviting trouble. It appears that the >> underlying problem is that "/" is not a token character, and that RFC >> 3261 restricts algorithm values to being tokens. >> >> >> How do you suggest I fix that? >> >> >> Two algorithms are called "SHA2-256" and "SHA2-512/256". But the >> standard names for these two algorithms seem to be "SHA-256" and >> "SHA-512/256", looking at the Wikipedia page "SHA-2" and mentions of >> these algorithms in the titles of various RFCs. >> >> >> Ok, I will change the name to align with the standard name. >> >> The use of "-sess" seems to be poorly specified. Much of the text >> treats algorithm values ending in "-sess" opaquely, in that certain >> enumerated algorithm values that happen to end in "-sess" cause the A1 >> processing to be modified. But the intention seems to be that "-sess" >> is a *modifier* of an algorithm that is otherwise defined. It seems >> like there should be a specification of the meaning of "-sess" that is >> orthogonal to the algorithm name proper. >> >> >> I need to think about this one. >> > > I've been trying to get at this too. It is really a defect in the original > definition of digest, but it is how hard to get out of. > > Till now my suggestion has been that it is just up to each new algorithm > to specify a -sess variant if appropriate, and to define it. > > If it will always be the case that every new algorithm should have a -sess > variant and a non-sess variant, and that the difference between them can be > defined once, then it would be better to do that, and change the syntax to > just in clude a [ "-sess" ] and a common definition of what that means. > > > Ok. I will add the details of the meaning of the -sess variant to the document. > Section 2.3 says, "If the UAS challenges with multiple >> WWW-Authenticate/Proxy- Authenticate headers, then each one of these >> headers MUST use a different digest algorithm." >> >> We don't want this restriction because it would forbid the UAS to >> provide multiple challenges with different realms but the same >> algorithm. In addition, this restriction provides no benefit to UACs, >> because when a proxy aggregates challenges, even if the UASs are >> following this rule, the aggregated challenge may not follow this >> rule. >> >> >> I will clarify it to make it clear that this limitation is for multiple >> headers with the same realm. >> >> Section 2.3 says, "The UAS MUST add these headers to the response in >> order of strength of the algorithm, starting with the strongest >> algorithm, followed by the less strong algorithms." >> >> I think the rule you want is that the challenges should be listed in >> the order that the UAS would prefer to see them used. In general, >> this SHOULD be in order of cryptographic strength, but there could be >> other considerations, and it's possible that the consensus of >> cryptographic strength could change over time, leaving an >> implementation out-of-compliance. >> >> >> Good point. I will fix it. >> >> Section 2.4 says, "If the UAC does not support any of the algorithms >> in the response, then it should abandon attempts to send the request." >> >> I think this can be generalized to "If the UAC cannot respond to any >> of the challenges in the response ..."; e.g., if the UAC does not have >> credentials for any of the realms. >> >> >> Ok >> > > I think that is too strong. Suppose the request has been forked, with > separate challenges from each fork, and the proxy has merged them. If the > UAC can only respond to one of the challenges, that should be ok. Then one > fork will work and the other will not. > > Hmmm. How is that different from Dale's proposal. If I paraphrase what Dale is saying, I understand it to say: "if the UAC is not able to respond to at least one challenge..." Regards, Rifaat > Section 2.5 says, "When the forking proxy places multiple >> WWW-Authenticate and Proxy-Authenticate header fields from one proxy >> into the single response it MUST maintain the order of these header >> fields. The ordering of the header field values from the various >> proxies is not significant." >> >> I think "one proxy" should be "one received response". >> >> >> Ok. >> >> >> In theory, it may not be possible for the proxy to both remove all >> duplicates from the list and also maintain the order from each >> received response (since two duplicated headers might appear in >> opposite orders in two responses). But I think that is impossible >> unless two received responses can have headers with the same nonce >> value. >> >> Section 2.6 says, "The SIP scheme usage is almost completely identical >> to that for HTTP." >> >> I'd prefer "... is similar to that for HTTP." given that the >> differences are quite significant (especially in that the request URI >> is not protected). >> >> >> Ok. >> >> Section 2.6 says, "This section does NOT maintain backward >> compatibility with RFC 2543." >> >> This statement needs to be fleshed out. In one sense, it is not >> backward compatible with *RFC 3261*, because it requires UAs to fully >> support "qop" -- UAs that are compliant with RFC 3261 but don't >> support "qop" are not compliant with the modified RFC 3261. >> >> On the other hand, as long as UAs can deal with their other-ends not >> supporting "qop" (which I expect to be the universal implementation >> practice), then they are *compatible* with such UAs. >> >> There is also the problem that "compatibility with RFC 2543" is used >> to mean "compatibility with RFC 2069 (which was referenced in early >> drafts of RFC 2543)". I'm not sure if that's technically incorrect, >> but it would probably be clearer to state "RFC 2069" directly. >> >> >> How about replacing the MUST with SHOULD in section 2.6, bullet 7, as >> follows: >> >> Servers SHOULD be able to properly handle "qop" parameter received >> in an authorization header field, and clients SHOULD be able to >> properly handle "qop" parameter received in WWW-Authenticate and >> Proxy-Authenticate header fields. >> >> Servers MUST always send a "qop" parameter in WWW-Authenticate >> and Proxy-Authenticate header field values, and clients MUST >> send the "qop" parameter in any resulting authorization header >> field. >> >> >> Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache >> operation does not apply to SIP." >> >> There are some tricky issues surrounding the binding-time of the >> reference "[17]". For clarity, this probably needs to be turned into >> a reference that is resolved within this document. >> >> >> Yes. >> >> And a comment about draft-ietf-httpauth-digest-04: >> >> This draft creates a registry named "HTTP Digest Hash Algorithms". >> There is already a registry named "HTTP Digest Algorithm Values" >> (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml). >> That latter registry has a different purpose, similar algorithm names, >> and specifies that the algorithm outputs are to be presented in >> base64. I think there is a significant danger of confusion, but it >> would also be difficult to combine them. >> >> >> Yeah, it might confuse people. Do you have a better name for this >> registry? >> >> Regards, >> Rifaat >> >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c3fb70c55b1804f0b77979 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Thu, Jan 23, 2014 at 10:24 PM, Paul Kyzivat <pkyzivat@= alum.mit.edu> wrote:
I have added a few comments inline.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 1/23/14 8:27 PM, Rifaat Shekh-Yusef wrote:
Hi Dale,

Thanks a lot for these great comments.
See my reply inline...

Regards,
=A0 Rifaat



On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley <worley@ariadne.com
<mailto:worley@a= riadne.com>> wrote:

=A0 =A0 Here are some comments on draft-yusef-sipcore-digest-scheme-= 03:

=A0 =A0 Section 2 says, "This section describes the modifications to t= he
=A0 =A0 operation of the Digest mechanism as specified in RFC3261."
=A0 =A0 I think it would be helpful here to also point to HTTP-DIGEST by =A0 =A0 adding "... in order to support the SHA2-256 and SHA2-512/256<= br> =A0 =A0 algorithms as described in [HTTP-DIGEST], and also to require suppo= rt
=A0 =A0 for the "qop" option."


Ok

=A0 =A0 The text is a bit hazy about the distinction between the *name* of = the
=A0 =A0 algorithm and the "algorithm" value that is used to speci= fy the
=A0 =A0 algorithm. =A0In particular, one algorithm is *called* "SHA2-5= 12/256",
=A0 =A0 but its corresponding *value* is "SHA2-512-256". =A0This = is easy enough
=A0 =A0 to understand, but it may be inviting trouble. =A0It appears that t= he
=A0 =A0 underlying problem is that "/" is not a token character, = and that RFC
=A0 =A0 3261 restricts algorithm values to being tokens.


How do you suggest I fix that?


=A0 =A0 Two algorithms are called "SHA2-256" and "SHA2-512/2= 56". =A0But the
=A0 =A0 standard names for these two algorithms seem to be =A0"SHA-256= " and
=A0 =A0 "SHA-512/256", looking at the Wikipedia page "SHA-2&= quot; and mentions of
=A0 =A0 these algorithms in the titles of various RFCs.


Ok, I will change the name to align with the standard name.

=A0 =A0 The use of "-sess" seems to be poorly specified. =A0Much = of the text
=A0 =A0 treats algorithm values ending in "-sess" opaquely, in th= at certain
=A0 =A0 enumerated algorithm values that happen to end in "-sess"= cause the A1
=A0 =A0 processing to be modified. =A0But the intention seems to be that &q= uot;-sess"
=A0 =A0 is a *modifier* of an algorithm that is otherwise defined. =A0It se= ems
=A0 =A0 like there should be a specification of the meaning of "-sess&= quot; that is
=A0 =A0 orthogonal to the algorithm name proper.


I need to think about this one.

I've been trying to get at this too. It is really a defect in the origi= nal definition of digest, but it is how hard to get out of.

Till now my suggestion has been that it is just up to each new algorithm to= specify a -sess variant if appropriate, and to define it.

If it will always be the case that every new algorithm should have a -sess = variant and a non-sess variant, and that the difference between them can be= defined once, then it would be better to do that, and change the syntax to= just in clude a [ "-sess" ] and a common definition of what that= means.



Ok. I will add the details= of the meaning of the -sess variant to the document.

<= div>
=A0
=A0 =A0 Section 2.3 says, "If the UAS challenges with multiple
=A0 =A0 WWW-Authenticate/Proxy- Authenticate headers, then each one of thes= e
=A0 =A0 headers MUST use a different digest algorithm."

=A0 =A0 We don't want this restriction because it would forbid the UAS = to
=A0 =A0 provide multiple challenges with different realms but the same
=A0 =A0 algorithm. =A0In addition, this restriction provides no benefit to = UACs,
=A0 =A0 because when a proxy aggregates challenges, even if the UASs are =A0 =A0 following this rule, the aggregated challenge may not follow this =A0 =A0 rule.


I will clarify it to make it clear that this limitation is for multiple
headers with the same realm.

=A0 =A0 Section 2.3 says, "The UAS MUST add these headers to the respo= nse in
=A0 =A0 order of strength of the algorithm, starting with the strongest
=A0 =A0 algorithm, followed by the less strong algorithms."

=A0 =A0 I think the rule you want is that the challenges should be listed i= n
=A0 =A0 the order that the UAS would prefer to see them used. =A0In general= ,
=A0 =A0 this SHOULD be in order of cryptographic strength, but there could = be
=A0 =A0 other considerations, and it's possible that the consensus of =A0 =A0 cryptographic strength could change over time, leaving an
=A0 =A0 implementation out-of-compliance.


Good point. I will fix it.

=A0 =A0 Section 2.4 says, "If the UAC does not support any of the algo= rithms
=A0 =A0 in the response, then it should abandon attempts to send the reques= t."

=A0 =A0 I think this can be generalized to "If the UAC cannot respond = to any
=A0 =A0 of the challenges in the response ..."; e.g., if the UAC does = not have
=A0 =A0 credentials for any of the realms.


Ok

I think that is too strong. Suppose the request has been forked, with separ= ate challenges from each fork, and the proxy has merged them. If the UAC ca= n only respond to one of the challenges, that should be ok. Then one fork w= ill work and the other will not.

=A0
Hmmm. How is that different from Dale&#= 39;s proposal.
If I paraphrase what Dale is saying, I understand = it to say: "if the UAC is not able to respond to at least one challeng= e..."

Regards,
=A0Rifaat

=
=A0
=A0 =A0 Section 2.5 says, "When the forking proxy places multiple
=A0 =A0 WWW-Authenticate and Proxy-Authenticate header fields from one prox= y
=A0 =A0 into the single response it MUST maintain the order of these header=
=A0 =A0 fields. The ordering of the header field values from the various =A0 =A0 proxies is not significant."

=A0 =A0 I think "one proxy" should be "one received response= ".


Ok.


=A0 =A0 In theory, it may not be possible for the proxy to both remove all<= br> =A0 =A0 duplicates from the list and also maintain the order from each
=A0 =A0 received response (since two duplicated headers might appear in
=A0 =A0 opposite orders in two responses). =A0But I think that is impossibl= e
=A0 =A0 unless two received responses can have headers with the same nonce<= br> =A0 =A0 value.

=A0 =A0 Section 2.6 says, "The SIP scheme usage is almost completely i= dentical
=A0 =A0 to that for HTTP."

=A0 =A0 I'd prefer "... is similar to that for HTTP." given t= hat the
=A0 =A0 differences are quite significant (especially in that the request U= RI
=A0 =A0 is not protected).


Ok.

=A0 =A0 Section 2.6 says, "This section does NOT maintain backward
=A0 =A0 compatibility with RFC 2543."

=A0 =A0 This statement needs to be fleshed out. =A0In one sense, it is not<= br> =A0 =A0 backward compatible with *RFC 3261*, because it requires UAs to ful= ly
=A0 =A0 support "qop" -- UAs that are compliant with RFC 3261 but= don't
=A0 =A0 support "qop" are not compliant with the modified RFC 326= 1.

=A0 =A0 On the other hand, as long as UAs can deal with their other-ends no= t
=A0 =A0 supporting "qop" (which I expect to be the universal impl= ementation
=A0 =A0 practice), then they are *compatible* with such UAs.

=A0 =A0 There is also the problem that "compatibility with RFC 2543&qu= ot; is used
=A0 =A0 to mean "compatibility with RFC 2069 (which was referenced in = early
=A0 =A0 drafts of RFC 2543)". =A0I'm not sure if that's techni= cally incorrect,
=A0 =A0 but it would probably be clearer to state "RFC 2069" dire= ctly.


How about replacing the MUST with SHOULD in section 2.6, bullet 7, as
follows:

=A0 =A0 Servers SHOULD be able to properly handle "qop" parameter= received
=A0 =A0 in an authorization header field, and clients SHOULD be able to
=A0 =A0 properly handle "qop" parameter received in WWW-Authentic= ate and
=A0 =A0 Proxy-Authenticate header fields.

=A0 =A0 Servers MUST always send a "qop" parameter in WWW-Authent= icate
=A0 =A0 and Proxy-Authenticate header field values, and clients MUST
=A0 =A0 send the "qop" parameter in any resulting authorization h= eader
=A0 =A0 field.


=A0 =A0 Section 2.6 says, "4. The text in RFC 2617 [17] regarding cach= e
=A0 =A0 operation does not apply to SIP."

=A0 =A0 There are some tricky issues surrounding the binding-time of the =A0 =A0 reference "[17]". =A0For clarity, this probably needs to = be turned into
=A0 =A0 a reference that is resolved within this document.


Yes.

=A0 =A0 And a comment about draft-ietf-httpauth-digest-04:

=A0 =A0 This draft creates a registry named "HTTP Digest Hash Algorith= ms".
=A0 =A0 There is already a registry named "HTTP Digest Algorithm Value= s"
=A0 =A0 (http://www.iana.org/assignments/http-dig= -alg/http-dig-alg.xhtml).
=A0 =A0 That latter registry has a different purpose, similar algorithm nam= es,
=A0 =A0 and specifies that the algorithm outputs are to be presented in
=A0 =A0 base64. =A0I think there is a significant danger of confusion, but = it
=A0 =A0 would also be difficult to combine them.


Yeah, it might confuse people. Do you have a better name for this registry?=

Regards,
=A0 Rifaat


=A0 =A0 Dale
=A0 =A0 _______________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore





_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a11c3fb70c55b1804f0b77979-- From pkyzivat@alum.mit.edu Fri Jan 24 08:36:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA61A04AF for ; Fri, 24 Jan 2014 08:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Ap-g22oACO for ; Fri, 24 Jan 2014 08:36:07 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id DAB841A0010 for ; Fri, 24 Jan 2014 08:36:06 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id Hp5k1n0051HzFnQ58sc5MF; Fri, 24 Jan 2014 16:36:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Hsc51n0073ZTu2S3asc5cd; Fri, 24 Jan 2014 16:36:05 +0000 Message-ID: <52E29675.3030004@alum.mit.edu> Date: Fri, 24 Jan 2014 11:36:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390581365; bh=WiIYWMKeJcOF0Gocgf8g+/A2KqpI7sULjqAK6Flae+I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JCWHOlv2TMq0fKAAO/0Ow8BG3P/lYf+JITaf9JV2IisPODRCZBSa5rOcuZa3r02e7 iDt9JZmWUdSd0E6ktscyXQ65uAhQabKQ+2nNt0bqGg52HE04iP6ZZrgPEZ9xWx0KXm jmTB/as3TBsGW2iSNdH7TCl4NmalcsAS8G/6sjakevumHrqH7aiDLxnHAu/P7McC66 w6zBnv21vSikxddA5Xv3ZCaSyVCgzcza1aaGKFxKewMNt1JfM4rKD84gQWsszja0KI voDA+YMhKufUxCNCkfhHeQOmFDws5leR3CN7SFzwiMy5QjeFzhLsjh2MgE2O7I7wSu gXlGZLdnSrPMg== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:36:09 -0000 On 1/24/14 8:38 AM, Rifaat Shekh-Yusef wrote: > Inline... > > > On Thu, Jan 23, 2014 at 10:24 PM, Paul Kyzivat > wrote: > > I have added a few comments inline. > > Thanks, > Paul > > > On 1/23/14 8:27 PM, Rifaat Shekh-Yusef wrote: > > Hi Dale, > > Thanks a lot for these great comments. > See my reply inline... > > Regards, > Rifaat > > > > On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley > > >> wrote: > > Here are some comments on > draft-yusef-sipcore-digest-__scheme-03: > > Section 2 says, "This section describes the modifications > to the > operation of the Digest mechanism as specified in RFC3261." > > I think it would be helpful here to also point to > HTTP-DIGEST by > adding "... in order to support the SHA2-256 and SHA2-512/256 > algorithms as described in [HTTP-DIGEST], and also to > require support > for the "qop" option." > > > Ok > > The text is a bit hazy about the distinction between the > *name* of the > algorithm and the "algorithm" value that is used to specify the > algorithm. In particular, one algorithm is *called* > "SHA2-512/256", > but its corresponding *value* is "SHA2-512-256". This is > easy enough > to understand, but it may be inviting trouble. It appears > that the > underlying problem is that "/" is not a token character, > and that RFC > 3261 restricts algorithm values to being tokens. > > > How do you suggest I fix that? > > > Two algorithms are called "SHA2-256" and "SHA2-512/256". > But the > standard names for these two algorithms seem to be > "SHA-256" and > "SHA-512/256", looking at the Wikipedia page "SHA-2" and > mentions of > these algorithms in the titles of various RFCs. > > > Ok, I will change the name to align with the standard name. > > The use of "-sess" seems to be poorly specified. Much of > the text > treats algorithm values ending in "-sess" opaquely, in that > certain > enumerated algorithm values that happen to end in "-sess" > cause the A1 > processing to be modified. But the intention seems to be > that "-sess" > is a *modifier* of an algorithm that is otherwise defined. > It seems > like there should be a specification of the meaning of > "-sess" that is > orthogonal to the algorithm name proper. > > > I need to think about this one. > > > I've been trying to get at this too. It is really a defect in the > original definition of digest, but it is how hard to get out of. > > Till now my suggestion has been that it is just up to each new > algorithm to specify a -sess variant if appropriate, and to define it. > > If it will always be the case that every new algorithm should have a > -sess variant and a non-sess variant, and that the difference > between them can be defined once, then it would be better to do > that, and change the syntax to just in clude a [ "-sess" ] and a > common definition of what that means. > > > > Ok. I will add the details of the meaning of the -sess variant to the > document. IIUC, this needs to be in [HTTP-DIGEST], not *this* document. Right? > Section 2.3 says, "If the UAS challenges with multiple > WWW-Authenticate/Proxy- Authenticate headers, then each one > of these > headers MUST use a different digest algorithm." > > We don't want this restriction because it would forbid the > UAS to > provide multiple challenges with different realms but the same > algorithm. In addition, this restriction provides no > benefit to UACs, > because when a proxy aggregates challenges, even if the > UASs are > following this rule, the aggregated challenge may not > follow this > rule. > > > I will clarify it to make it clear that this limitation is for > multiple > headers with the same realm. > > Section 2.3 says, "The UAS MUST add these headers to the > response in > order of strength of the algorithm, starting with the strongest > algorithm, followed by the less strong algorithms." > > I think the rule you want is that the challenges should be > listed in > the order that the UAS would prefer to see them used. In > general, > this SHOULD be in order of cryptographic strength, but > there could be > other considerations, and it's possible that the consensus of > cryptographic strength could change over time, leaving an > implementation out-of-compliance. > > > Good point. I will fix it. > > Section 2.4 says, "If the UAC does not support any of the > algorithms > in the response, then it should abandon attempts to send > the request." > > I think this can be generalized to "If the UAC cannot > respond to any > of the challenges in the response ..."; e.g., if the UAC > does not have > credentials for any of the realms. > > > Ok > > > I think that is too strong. Suppose the request has been forked, > with separate challenges from each fork, and the proxy has merged > them. If the UAC can only respond to one of the challenges, that > should be ok. Then one fork will work and the other will not. > > Hmmm. How is that different from Dale's proposal. > If I paraphrase what Dale is saying, I understand it to say: "if the UAC > is not able to respond to at least one challenge..." Maybe I read it wrong and we are all saying the same thing. But it is tricky. If there are multiple challenges on a single fork, then those all need to be answered to be successful, but if they are on different forks then maybe not. So how do you decide when to give up, to avoid retrying forever? Thanks, Paul > Regards, > Rifaat > > Section 2.5 says, "When the forking proxy places multiple > WWW-Authenticate and Proxy-Authenticate header fields from > one proxy > into the single response it MUST maintain the order of > these header > fields. The ordering of the header field values from the > various > proxies is not significant." > > I think "one proxy" should be "one received response". > > > Ok. > > > In theory, it may not be possible for the proxy to both > remove all > duplicates from the list and also maintain the order from each > received response (since two duplicated headers might appear in > opposite orders in two responses). But I think that is > impossible > unless two received responses can have headers with the > same nonce > value. > > Section 2.6 says, "The SIP scheme usage is almost > completely identical > to that for HTTP." > > I'd prefer "... is similar to that for HTTP." given that the > differences are quite significant (especially in that the > request URI > is not protected). > > > Ok. > > Section 2.6 says, "This section does NOT maintain backward > compatibility with RFC 2543." > > This statement needs to be fleshed out. In one sense, it > is not > backward compatible with *RFC 3261*, because it requires > UAs to fully > support "qop" -- UAs that are compliant with RFC 3261 but don't > support "qop" are not compliant with the modified RFC 3261. > > On the other hand, as long as UAs can deal with their > other-ends not > supporting "qop" (which I expect to be the universal > implementation > practice), then they are *compatible* with such UAs. > > There is also the problem that "compatibility with RFC > 2543" is used > to mean "compatibility with RFC 2069 (which was referenced > in early > drafts of RFC 2543)". I'm not sure if that's technically > incorrect, > but it would probably be clearer to state "RFC 2069" directly. > > > How about replacing the MUST with SHOULD in section 2.6, bullet > 7, as > follows: > > Servers SHOULD be able to properly handle "qop" parameter > received > in an authorization header field, and clients SHOULD be able to > properly handle "qop" parameter received in > WWW-Authenticate and > Proxy-Authenticate header fields. > > Servers MUST always send a "qop" parameter in WWW-Authenticate > and Proxy-Authenticate header field values, and clients MUST > send the "qop" parameter in any resulting authorization header > field. > > > Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache > operation does not apply to SIP." > > There are some tricky issues surrounding the binding-time > of the > reference "[17]". For clarity, this probably needs to be > turned into > a reference that is resolved within this document. > > > Yes. > > And a comment about draft-ietf-httpauth-digest-04: > > This draft creates a registry named "HTTP Digest Hash > Algorithms". > There is already a registry named "HTTP Digest Algorithm > Values" > > (http://www.iana.org/__assignments/http-dig-alg/http-__dig-alg.xhtml > ). > That latter registry has a different purpose, similar > algorithm names, > and specifies that the algorithm outputs are to be presented in > base64. I think there is a significant danger of > confusion, but it > would also be difficult to combine them. > > > Yeah, it might confuse people. Do you have a better name for > this registry? > > Regards, > Rifaat > > > Dale > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > > > https://www.ietf.org/mailman/__listinfo/sipcore > > > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From worley@shell01.TheWorld.com Fri Jan 24 14:20:10 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28991A0185 for ; Fri, 24 Jan 2014 14:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv1mxBsIu854 for ; Fri, 24 Jan 2014 14:20:07 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 24ADD1A01E1 for ; Fri, 24 Jan 2014 14:20:06 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0OMK0L2004506; Fri, 24 Jan 2014 17:20:02 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0OMEwHM3519613; Fri, 24 Jan 2014 17:14:58 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0OMEvwU3517611; Fri, 24 Jan 2014 17:14:57 -0500 (EST) Date: Fri, 24 Jan 2014 17:14:57 -0500 (EST) Message-Id: <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <52E29675.3030004@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> Cc: sipcore@ietf.org, rifaat.ietf@gmail.com Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:20:10 -0000 > > Section 2.4 says, "If the UAC does not support any of > > the algorithms in the response, then it should > > abandon attempts to send the request." > > > > I think this can be generalized to "If the UAC cannot > > respond to any of the challenges in the response > > ..."; e.g., if the UAC does not have credentials for > > any of the realms. > > > > I think that is too strong. Suppose the request has been forked, > > with separate challenges from each fork, and the proxy has merged > > them. If the UAC can only respond to one of the challenges, that > > should be ok. Then one fork will work and the other will not. > > > > Hmmm. How is that different from Dale's proposal. > > If I paraphrase what Dale is saying, I understand it to say: "if the UAC > > is not able to respond to at least one challenge..." > > Maybe I read it wrong and we are all saying the same thing. > > But it is tricky. If there are multiple challenges on a single fork, > then those all need to be answered to be successful, but if they are on > different forks then maybe not. So how do you decide when to give up, to > avoid retrying forever? Maybe there is a deeper question. I have been *assuming* that if a UAS puts multiple challenges in its response, then the UAC can successfully resend the request (to that UAS) if it provides (valid) credentials for *any one* challenge. With this assumption, the natural course of action for a UAC, when challenged, is to resend the request with all credentials that it possesses that match any one of the challenges. And if it possesses no such credential to give up. And the UAC has to behave that way anyway, because it does not know which challenges came from the same UAS and which came from different UASs. What if a UAS requires more than one credential? ... That works as well, because the UAC will provide multiple credentials, and if the UAC happens to provide a sufficient set to convince the UAS, the UAS will accept the request. It seems that in any of these cases, the UAC should provide credentials for every challenge for which it has matching credentials. Only if the UAC has no credentials for any of the challenges does the UAC know for certain that the resend will fail. > From: Paul Kyzivat > > Ok. I will add the details of the meaning of the -sess variant to the > > document. > > IIUC, this needs to be in [HTTP-DIGEST], not *this* document. Right? Hmmm, yes, I overlooked that -sess isn't used with SIP. Perhaps draft-yusef-sipcore-digest-scheme should state that the -sess variants aren't used with SIP? > From: Rifaat Shekh-Yusef > > The text is a bit hazy about the distinction between the *name* of the > > algorithm and the "algorithm" value that is used to specify the > > algorithm. In particular, one algorithm is *called* "SHA2-512/256", > > but its corresponding *value* is "SHA2-512-256". This is easy enough > > to understand, but it may be inviting trouble. It appears that the > > underlying problem is that "/" is not a token character, and that RFC > > 3261 restricts algorithm values to being tokens. > > > How do you suggest I fix that? I'm not sure that there is a good fix. Thinking about it again, perhaps what is bothering me is that draft-yusef-sipcore-digest-scheme does not state the values of "algorithm" that are valid for SIP, it only gives the algorithm names. OTOH, the algorithm names are translated into values by the registry table. OTOOH, that fact doesn't seem to be mentioned in the draft. Perhaps add a sentence to the beginning of 2.1: The Digest scheme has an 'algorithm' parameter that specifies the algorithm to be used to compute the digest of the response. The IANA registry named "..." specifies the algorithms that correspond to 'algorithm' values. And revise the IANA Considerations to mention that. (This should be parallel to text in HTTP-DIGEST.) > > Section 2.6 says, "This section does NOT maintain backward > > compatibility with RFC 2543." > > > > This statement needs to be fleshed out. In one sense, it is not > > backward compatible with *RFC 3261*, because it requires UAs to fully > > support "qop" -- UAs that are compliant with RFC 3261 but don't > > support "qop" are not compliant with the modified RFC 3261. > > > > On the other hand, as long as UAs can deal with their other-ends not > > supporting "qop" (which I expect to be the universal implementation > > practice), then they are *compatible* with such UAs. > > > > There is also the problem that "compatibility with RFC 2543" is used > > to mean "compatibility with RFC 2069 (which was referenced in early > > drafts of RFC 2543)". I'm not sure if that's technically incorrect, > > but it would probably be clearer to state "RFC 2069" directly. > > > > > How about replacing the MUST with SHOULD in section 2.6, bullet 7, as > follows: > > Servers SHOULD be able to properly handle "qop" parameter received > in an authorization header field, and clients SHOULD be able to > properly handle "qop" parameter received in WWW-Authenticate and > Proxy-Authenticate header fields. > > Servers MUST always send a "qop" parameter in WWW-Authenticate > and Proxy-Authenticate header field values, and clients MUST > send the "qop" parameter in any resulting authorization header > field. Assuming that your intention is (1) for a UA to be conformant to this spec, it must generate qop when possible and respond to qop when qop is present in the challenge, and (2) to interoperate with UAs that do not support qop (those implemented to RFC 2069 and called "RFC 2543"), ISTM that your normative text is correct. All I want is more detailed explanation where the compatilities and incompatibilities lie. Perhaps: This document requires UAs to provide "qop" in challenges and to provide "qop" in responses to challenges that provide "qop". Thus UAs that are compliant to RFC 3261 or RFC 2543 (which are based on RFC 2617) are not compliant to this document unless they implement "qop". UAs that are compliant with this document will interoperate with UAs that do not implement "qop" (as described in RFC 2617). That's not exactly how I want to say it, but I think it gives the idea. > > And a comment about draft-ietf-httpauth-digest-04: > > > > This draft creates a registry named "HTTP Digest Hash Algorithms". > > There is already a registry named "HTTP Digest Algorithm Values" > > (http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml). > > That latter registry has a different purpose, similar algorithm names, > > and specifies that the algorithm outputs are to be presented in > > base64. I think there is a significant danger of confusion, but it > > would also be difficult to combine them. > > > Yeah, it might confuse people. Do you have a better name for this registry? The ideal thing would be to combine the two registries. You could almost do that, except that the existing registry is for use with RFC 3230 (the HTTP "Digest" header), and specifies the encoding to be used on the hash output. And for the algorithms we are talking about, that encoding is specified as base64, not hex. I suppose "HTTP Digest Authentication Algorithm Values" would be correct, although the potential for confusion is high. Unfortunately it is probably not worth the effort to define a unified registry and update all the relevant documents to deal with the (somewhat different) unified registry. Dale From pkyzivat@alum.mit.edu Fri Jan 24 15:05:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24F11A0205 for ; Fri, 24 Jan 2014 15:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyq1jks9ODRO for ; Fri, 24 Jan 2014 15:05:24 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 15E971A01F5 for ; Fri, 24 Jan 2014 15:05:23 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id Hx6k1n0031c6gX854z5NDB; Fri, 24 Jan 2014 23:05:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Hz5N1n00J3ZTu2S3jz5NXC; Fri, 24 Jan 2014 23:05:22 +0000 Message-ID: <52E2F1B2.5060702@alum.mit.edu> Date: Fri, 24 Jan 2014 18:05:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> In-Reply-To: <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390604722; bh=v16wzP0z8DGpSxTezpTCUlPqAgup3ocFNQUH/B4QG6c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=frklRo1ktRETsNqT0GqMiJnjHRea6dmfoJsLkEVE293G/8N3U838fAjSBAWwl5Hch Q+E3ZzeGFZfyZtvRAIeThdMSXcetzYA/sHBicQxWt76GWTDMvgjCGrzmtv/ghfWkZf /zvY++rpn+kK6yjDnKv+As5TP3JvDiXGobaZPqP2qRqO/GBwShEugJpGRV/AIV/OS0 Y3wnpBg/dCLGkNk6zpGs3cFhtyODrge4KgVtbF3rRCOkt60DCGltsHh0S9W1V3EyTd d9kP7k9z3M1x5t1X+Gr4hFE5vIRUBjWo1v/8twmuHLRPCt+r2Iz2dAQoz0hTIXI4KA gAVqi2B1/GJQA== Cc: sipcore@ietf.org, rifaat.ietf@gmail.com Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:05:25 -0000 On 1/24/14 5:14 PM, Dale R. Worley wrote: >>> Section 2.4 says, "If the UAC does not support any of >>> the algorithms in the response, then it should >>> abandon attempts to send the request." >>> >>> I think this can be generalized to "If the UAC cannot >>> respond to any of the challenges in the response >>> ..."; e.g., if the UAC does not have credentials for >>> any of the realms. >>> >>> I think that is too strong. Suppose the request has been forked, >>> with separate challenges from each fork, and the proxy has merged >>> them. If the UAC can only respond to one of the challenges, that >>> should be ok. Then one fork will work and the other will not. >>> >>> Hmmm. How is that different from Dale's proposal. >>> If I paraphrase what Dale is saying, I understand it to say: "if the UAC >>> is not able to respond to at least one challenge..." >> >> Maybe I read it wrong and we are all saying the same thing. >> >> But it is tricky. If there are multiple challenges on a single fork, >> then those all need to be answered to be successful, but if they are on >> different forks then maybe not. So how do you decide when to give up, to >> avoid retrying forever? > > Maybe there is a deeper question. > > I have been *assuming* that if a UAS puts multiple challenges in its > response, then the UAC can successfully resend the request (to that > UAS) if it provides (valid) credentials for *any one* challenge. > > With this assumption, the natural course of action for a UAC, when > challenged, is to resend the request with all credentials that it > possesses that match any one of the challenges. And if it possesses > no such credential to give up. > > And the UAC has to behave that way anyway, because it does not know > which challenges came from the same UAS and which came from different > UASs. > > What if a UAS requires more than one credential? ... That works as > well, because the UAC will provide multiple credentials, and if the > UAC happens to provide a sufficient set to convince the UAS, the UAS > will accept the request. On any one path you should have at most one UAS challenging, but may have several proxies. So you would need to provide credentials for each of those. When forking, those could be merged from multiple paths. The UAC, for a successful retry, will at least need to successfully respond to all the challenges from one of the paths. > It seems that in any of these cases, the UAC should provide > credentials for every challenge for which it has matching credentials. > Only if the UAC has no credentials for any of the challenges does the > UAC know for certain that the resend will fail. Certainly it should respond to everything it can. But how does it know when to give up? I guess this really depends on circumstances. If it is prompting a user for passwords, then it can just keep trying. But if it is working only with stored credentials, then I guess it must keep track of which ones it has already supplied. If all the ones it can supply have already been tried then it needs to give up. But, contrary to my original suggestion, I guess we shouldn't be trying to give guidance here. (It is too implementation dependent.) Thanks, Paul From rifaat.ietf@gmail.com Sat Jan 25 05:49:36 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCE81A034F for ; Sat, 25 Jan 2014 05:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmMBIVrD4E62 for ; Sat, 25 Jan 2014 05:49:34 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6361A02B8 for ; Sat, 25 Jan 2014 05:49:34 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id c13so1404657eek.5 for ; Sat, 25 Jan 2014 05:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1UOaOok/VA2DcU+1IOBQLLmr8iTy9zlHrM4YBReUQ5k=; b=xEQTVOpeGagOPc0sRAy9/+mA2ZYSTfNA5Apnz5odnMcdk62Jz1AStYsgjeg8ItIAvZ 7yOJpkeTv9mhCi3NLflAJe+UKWq6qDXno5AkU3n3glxfOMRQXo0YsLo2Ogw+T2wpfrjl AKEwXIC7gWtUNdnD7hZYcrrIGEWeBvizQ2Z75Tqm29lmPkQDmn1Zg5FU9Lb9l0BIvQSU GQyEgRcqWwv6gEFMgab3UK5Q7NggULSezhYgeJlJOP6s6xMHq8iEwW27Pjw1QSgmqTR0 fgLg3eu8DnMjR1xVe0RWakzf6+tKAnmBBaMb7FI8LURNdLpFrlkiD9hkFxawytVzu0xk jFjg== MIME-Version: 1.0 X-Received: by 10.15.26.199 with SMTP id n47mr7797321eeu.30.1390657772121; Sat, 25 Jan 2014 05:49:32 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 25 Jan 2014 05:49:32 -0800 (PST) In-Reply-To: <20140125134253.20916.76333.idtracker@ietfa.amsl.com> References: <20140125134253.20916.76333.idtracker@ietfa.amsl.com> Date: Sat, 25 Jan 2014 08:49:32 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=089e01681bfe82f23404f0cbbe02 Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 13:49:36 -0000 --089e01681bfe82f23404f0cbbe02 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think that I have addressed all the comments that I received so far with the exception of the backward compatibility issue. Please, take a look and let me know if I missed something. On the backward compatibility issue, I still have the following question: ***[OPEN ISSUE]*** This section does NOT maintain backward compatibility with RFC 2069. Are there SIP servers and clients out there that support *only* RFC 2069 that would break because of this? Any thoughts on this? Thanks, Rifaat On Sat, Jan 25, 2014 at 8:42 AM, wrote: > > A new version of I-D, draft-yusef-sipcore-digest-scheme-04.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-sipcore-digest-scheme > Revision: 04 > Title: The Session Initiation Protocol (SIP) Digest > Authentication Scheme > Document date: 2014-01-25 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-04.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > Htmlized: > http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-04 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-yusef-sipcore-digest-scheme-04 > > Abstract: > This document updates the Digest Access Authentication scheme used by > the Session Initiation Protocol (SIP) to add support for SHA2 digest > algorithms to replace the MD5 algorithm. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --089e01681bfe82f23404f0cbbe02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think that I have addressed all t= he comments that I received so far with the exception of the backward compa= tibility issue.
Please, take a look and let me know if I missed s= omething.

On the backward compatibility issue, I still have the f= ollowing question:

***[OPEN ISSUE]***
This section does NOT maintain backward compatibility with RFC 2069.
<= /div>
Are there SIP servers and clients out there that support *only* RF=
C 2069 that would break because of this?

Any thoughts on this?

Thanks,
=A0Rifaat



On Sat, Jan 25, 2014 at 8:42 AM, <internet-drafts@ietf.org> wrote:

A new version of I-D, draft-yusef-sipcore-digest-scheme-04.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-scheme
Revision: =A0 =A0 =A0 04
Title: =A0 =A0 =A0 =A0 =A0The Session Initiation Protocol (SIP) Digest Auth= entication Scheme
Document date: =A02014-01-25
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A09
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-yusef-sipcore-digest-scheme-04.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-y= usef-sipcore-digest-scheme-04
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rf= cdiff?url2=3Ddraft-yusef-sipcore-digest-scheme-04

Abstract:
=A0 =A0This document updates the Digest Access Authentication scheme used b= y
=A0 =A0the Session Initiation Protocol (SIP) to add support for SHA2 digest=
=A0 =A0algorithms to replace the MD5 algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e01681bfe82f23404f0cbbe02-- From mary.ietf.barnes@gmail.com Sat Jan 25 09:29:40 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F94F1A005B; Sat, 25 Jan 2014 09:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7ITxc6_nACd; Sat, 25 Jan 2014 09:29:37 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9491A005A; Sat, 25 Jan 2014 09:29:37 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id at1so4199040iec.39 for ; Sat, 25 Jan 2014 09:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kgJJh9RuKzFrpELRa5QCKGNLEwfOswIDRUzL2d3yGEY=; b=JZArI/vUGfS1mKc+TTDEpQ3XMN40YTvmWE8O2B8NcThUbMs6S3Slh9lF33Z0O2Sj0R LyNv7vId/ZZsQdT2X17yweqLtw0jfZzPrz5NvaN0pxudwHa/PB/ZaQ9wv0yC4eX6wYDU rSS6hVURnPrkiPV6lWvh978qcnuCg0q5tdIQ738sh5F5NDy8z7oBtyPDs34BiVzPd6/0 DrcMMQweptge5KiDsMFubUULmqv2ivy1OqZmRpJy73K4x+iKeDum+gKFQr7Rxp7dtsGd ndksA35iRcPv+Ajq+eBDi1DTgzHdcMw+hM6n+QhAL4AobHIaS9VD5RQvU5+1k88XC3cd xHCg== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr10247664igb.0.1390670975274; Sat, 25 Jan 2014 09:29:35 -0800 (PST) Received: by 10.43.58.137 with HTTP; Sat, 25 Jan 2014 09:29:35 -0800 (PST) In-Reply-To: <52e18b8a.44668c0a.9b7c.ffffe95cSMTPIN_ADDED_BROKEN@mx.google.com> References: <52e18b8a.44668c0a.9b7c.ffffe95cSMTPIN_ADDED_BROKEN@mx.google.com> Date: Sat, 25 Jan 2014 11:29:35 -0600 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH , SIPCORE Content-Type: multipart/alternative; boundary=047d7b2e09837b14c504f0ced130 Subject: [sipcore] Fwd: [SIPForum-techwg] There's Still Time to Submit a SIPNOC 2014 Proposal X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:29:40 -0000 --047d7b2e09837b14c504f0ced130 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI all, The proposed topics for this conference are directly applicable to work in RAI WGs. Folks might want to consider submitting a contribution for the conference. Many of the attendees are folks that manage and operate the networks so you'll hear first hand of some of the challenges they have and it's a good opportunity to share some of the newer work that's happening that might help address some of their challenges. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Thu, Jan 23, 2014 at 3:33 PM Subject: [SIPForum-techwg] There's Still Time to Submit a SIPNOC 2014 Proposal To: techwg@sipforum.org There=E2=80=99s still time to submit a proposal for SIPNOC 2014 workshops, = panels, speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions add= ressing the deployment of SIP in service provider environments. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2014. Topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2014 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: The SIPNOC 2014 program has been expanded to include special workshops that run for 2-3 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. The following is a complete list of key dates for the SIPNOC 2014 speaking program: - Presentation Abstracts Due =E2=80=93 January 31, 2014 - Draft Presentations Due -- February 15, 2014 - Acceptance Decision and Notifications -- February 21, 2014 - Draft Program Published =E2=80=93 March 1, 2014 - Final Presentations Due -- April 1, 2014 - Final Agenda Published -- April 15, 2014 - Conference Begins -- June 9, 2014 ------------------------------ *SIPNOC 2014 General Info* The SIPNOC 2014 event website is located at www.sipnoc.org. Registration for SIPNOC 2014 is officially open! Special pricing for SIPNOC 2014 is now in effect! Take advantage of special early-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conference registration fee is $995, but for a limited time regular attendees can save $145 and pay only $850 for three days of conference proceedings. This fee includes a special welcome reception the evening before the event with food and drink; breakfast, lunch and break refreshments and snacks; and special networking receptions the first and second night of the event. *Individuals from SIP Forum Full Member companies save even more ($295 off the regular price to be exact with special early-bird pricing)! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at www.regonline.com/sipnoc2014. ------------------------------ *SIPNOC 2014 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2014, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --047d7b2e09837b14c504f0ced130 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI all,

The proposed topics for this co= nference are directly applicable to work in RAI WGs. =C2=A0Folks might want= to consider submitting a contribution for the conference. =C2=A0Many of th= e attendees are folks that manage and operate the networks so you'll he= ar first hand of some of the challenges they have and it's a good oppor= tunity to share some of the newer work that's happening that might help= address some of their challenges.

Regards,
Mary.=C2=A0


---------- Forwarded message ----------
= From: Marc Robins <<= a href=3D"mailto:marc.robins@sipforum.org">marc.robins@sipforum.org>=
Date: Thu, Jan 23, 2014 at 3:33 PM
Subject: [SIPForum-techwg] There'= s Still Time to Submit a SIPNOC 2014 Proposal
To: techwg@sipforum.org


There=E2=80=99s still time to subm= it a proposal for SIPNOC 2014 workshops, panels, speaker presentations and = =E2=80=9CBirds of a Feather=E2=80=9D sessions addressing the deployment of = SIP in service provider environments.

T= o view the official call for presentations, which includes instructions on = submitting material and specific SIPNOC policies, please visit www.sipforu= m.org/content/view/374/275/. To submit, visit https://www.e= asychair.org/conferences/?conf=3Dsipnoc2014.

T= opics can include SIP peering, SIP trunking, Emergency Services, Congestion= Control, Scaling and Capacity Issues, SIP-based applications, Routing, Sec= urity, SIP-Network Operations Center Best Practices, IPv6 deployment challe= nges, User-agent Configuration, Standardization Issues and Progress, HD voi= ce deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deploymen= t, Testing or other issues facing SIP network operations.

S= IPNOC 2014 offers several different types of speaking opportunities includi= ng:

  • General Session Talks: A General Session presen= tation should be on a topic of interest to the general SIPNOC audience, and= may be up to 30 minutes long (including time for Q&A). <= /span>
  • General Session Pa= nels: Panels are sessions with a moderator and a team of panelists. The pan= el moderator should submit an abstract on the panel topic, a list of paneli= sts, and how the panel will be organized. Panel selection is based on the i= mportance, originality, focus and timeliness of the topic, expertise of pro= posed panelists, as well as the potential for informative and controversial= discussion.
  • Special Workshops:= The SIPNOC 2014 program has been expanded to include special workshops tha= t run for 2-3 hours, providing time to focus in-depth on a variety of issue= s important to the SIPNOC community. Topics can include a review of SIP RFC= s and standards development, the regulatory environment, etc.=
  • Research Topics: R= esearchers are invited to present short summaries of their work for operato= r feedback. Topics may include call routing, network performance, statistic= al measurement and analysis and protocol development and implementation. St= udies presented may be works in progress. Researchers from academia, govern= ment, and industry are encouraged to present.
  • BOFs: BOFs (Birds = of a Feather sessions) are informal sessions on topics which are of interes= t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o= ut areas or in an unscheduled room. Requests for scheduled BOFs can be made= at any time, including on site at the conference.

The following is a complete list of key dates for the SIPNOC 2014 speak= ing program:

  • Presentation Abstracts Due =E2=80=93 Janua= ry 31, 2014
  • Draft Presentations Due -- February 15, 2014
  • Acceptance Decisio= n and Notifications -- February 21, 2014
  • Draft Program Published =E2= =80=93 March 1, 2014
  • Final Presentation= s Due -- April 1, 2014
  • Final Agenda Published -- April 15, 2014
  • Conference Begins = -- June 9, 2014

SIPNOC 2014 General Info

The SIPN= OC 2014 event website is located at www.sipnoc.org.

R= egistration for SIPNOC 2014 is officially open!

= Spec= ial pricing for SIPNOC 2014 is now in effect! Take advantage of special ear= ly-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conferen= ce registration fee is $995, but for a limited time regular attendees can s= ave $145 and pay only $850 for three days of conference proceedings. This f= ee includes a special welcome reception the evening before the event with f= ood and drink; breakfast, lunch and break refreshments and snacks; and spec= ial networking receptions the first and second night of the event.

Individuals from SIP Forum Full Member companies save even m= ore ($295 off the regular price to be exact with special early-bird pricing= )! Please contact Marc Robins, SIP Forum President and Managing Director, a= t marc.robins= @sipforum.org to obtain the exclusive Full Member discount code.=

R= egister today at www.regonline.com/sipnoc2014.=C2=A0

SIPNOC 2014 Sponsorship Information

F= or information about corporate sponsorship opportunities at SIPNOC 2014, pl= ease contact Marc Robins, SIP Forum President and Managing Director, at 203-829-= 6307 or m= arc.robins@sipforum.org.

=

*************************

Marc Robins

President and Managing Director<= u>

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307<= /p>

SkypeMe! marcrobins

=C2=A0

**************= ***********

=C2=A0

=C2=A0


________________________________________= _______
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg
--047d7b2e09837b14c504f0ced130-- From michael@voip.co.uk Sat Jan 25 12:04:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC60C1A0040 for ; Sat, 25 Jan 2014 12:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CikMRlsoW5rO for ; Sat, 25 Jan 2014 12:04:03 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 26E4D1A0027 for ; Sat, 25 Jan 2014 12:04:03 -0800 (PST) Received: from mail-wg0-f46.google.com ([74.125.82.46]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUuQYsTPltdlBM4iR3M49br8PbQKYIigV@postini.com; Sat, 25 Jan 2014 12:04:02 PST Received: by mail-wg0-f46.google.com with SMTP id x12so4138347wgg.1 for ; Sat, 25 Jan 2014 12:04:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D49kc7IzsOJ2Ab1N3iMJq83HPHfrnl38viNQLEkRfLc=; b=VJO/liyLizCCcbWMfyEW+7L0QQMCoN1I5/CbuG83mOiNHVr2BhQFbvxT7ecKy3o1Zq uMRwIFR/X1IkMW49RjVVwLdNp2XNCE9o3N5JB6tgTucN/xoN44y5jn+jsPYDtRZwaCTA 1hlic59V3kghTQ/d55Cs3GAMHTdAUfx1LNSzkViXCGcKfh2CeF9s6bZ2JF3F3ygYHIfk zTYituaPkSRrkutacNCEqjU+1B3dnT5raZsSG9m7uvqImJw8JFxXsn0Zyc9F/LXiRBYA u/bO5oVdAY8jycvVP6WM9UpswuRkSJ9cDm1SpiDkyYuv+AGoDkyhDDaD9tNB3sGBmI6j 5soA== X-Gm-Message-State: ALoCoQloM9XVWSme6GHy3TwvB+w5BDZrayyiau8GmDDwbYFoa2d8wqHh7pkorsljd3ukLgZRfTp/pj1T/I9HKmGw76oHZfHgqMphKIJs4SwrwK5qUNTYT6NCxhegBs9fcXR+vgiTdR7IP/flQ6f3606HKrSvpjbVqw== X-Received: by 10.180.12.146 with SMTP id y18mr7261725wib.37.1390680240390; Sat, 25 Jan 2014 12:04:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.12.146 with SMTP id y18mr7261719wib.37.1390680240236; Sat, 25 Jan 2014 12:04:00 -0800 (PST) Received: by 10.194.42.195 with HTTP; Sat, 25 Jan 2014 12:04:00 -0800 (PST) In-Reply-To: <52E2F1B2.5060702@alum.mit.edu> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> Date: Sat, 25 Jan 2014 20:04:00 +0000 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dale R. Worley" , SIPCORE , rifaat.ietf@gmail.com Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:04:06 -0000 On 24 January 2014 23:05, Paul Kyzivat wrote: > On 1/24/14 5:14 PM, Dale R. Worley wrote: >> It seems that in any of these cases, the UAC should provide >> credentials for every challenge for which it has matching credentials. >> Only if the UAC has no credentials for any of the challenges does the >> UAC know for certain that the resend will fail. > > Certainly it should respond to everything it can. That seems to disagree with draft-ietf-httpauth-digest section 5.5 which begins: An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth- scheme. A user agent MUST choose to use the strongest auth- scheme it understands and request credentials from the user based upon that challenge. If a UAS issues two challenges for the same realm but different auth-schemes, then it seems reasonable to only respond with the strongest supported auth-scheme. To respond with both a stronger and weaker algorithm seems unwise. But if a proxy aggregates two challenges for the same realm but with different auth-schemes, then as you both suggest, answering both challenges is most likely to succeed. RFC 3261 Section 22.3 last para addresses this scenario. Without being able to tell these two cases apart, I'm not sure a UAC is able to maximise the chances of a request succeeding at the same time as minimising the risk of using weaker auth-schemes when stronger ones may be supported. Michael From pkyzivat@alum.mit.edu Sat Jan 25 12:52:24 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962EF1A0045 for ; Sat, 25 Jan 2014 12:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK2WBqXQveJX for ; Sat, 25 Jan 2014 12:52:23 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id A8A1E1A003A for ; Sat, 25 Jan 2014 12:52:23 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id JLpH1n0021ap0As5CLsMl2; Sat, 25 Jan 2014 20:52:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id JLsM1n00B3ZTu2S3iLsMUu; Sat, 25 Jan 2014 20:52:21 +0000 Message-ID: <52E42405.3070005@alum.mit.edu> Date: Sat, 25 Jan 2014 15:52:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Michael Procter References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390683141; bh=/HbicK+PONRaSEZMewHwQB085rzbGCv4L5QOv2PuRr8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cc3M6jr65Ol740AgJYjcM2O+RuOv21NuzzKK6Wg7UAkEQh+lKpFJ6Pb0Y88LkgGSb GlT2fwMJ6QmPolJI2gSRleY30USaXSm9S2/m7W/r7OyGRSF4eUGw5z1dxDt+CH1jwO siunFNuS09YAgVcQKVke0rD6WuAjYGmARzf5MIRNhjkIbF2OnupWMB3LeBdY5JN6pS fsOoj/j0nLvAfs6ipQXkggWvgkXkPdsTYo5Mqb1khq8EMh68bIvj1Qej705Jd178p+ WJnJNzy3/7Or4dhoiyVJgdulEjPOUsZF92ZprewqR92wbq02ZOpA1GeOB+W6YgR7ev bVO/SA4hzJDoQ== Cc: "Dale R. Worley" , SIPCORE , rifaat.ietf@gmail.com Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:52:24 -0000 On 1/25/14 3:04 PM, Michael Procter wrote: > On 24 January 2014 23:05, Paul Kyzivat wrote: >> On 1/24/14 5:14 PM, Dale R. Worley wrote: >>> It seems that in any of these cases, the UAC should provide >>> credentials for every challenge for which it has matching credentials. >>> Only if the UAC has no credentials for any of the challenges does the >>> UAC know for certain that the resend will fail. >> >> Certainly it should respond to everything it can. > > That seems to disagree with draft-ietf-httpauth-digest section 5.5 which begins: > > An HTTP/1.1 server may return multiple challenges with a 401 > (Authenticate) response, and each challenge may use a different auth- > scheme. A user agent MUST choose to use the strongest auth- scheme it > understands and request credentials from the user based upon that > challenge. > > If a UAS issues two challenges for the same realm but different > auth-schemes, then it seems reasonable to only respond with the > strongest supported auth-scheme. To respond with both a stronger and > weaker algorithm seems unwise. > > But if a proxy aggregates two challenges for the same realm but with > different auth-schemes, then as you both suggest, answering both > challenges is most likely to succeed. RFC 3261 Section 22.3 last para > addresses this scenario. > > Without being able to tell these two cases apart, I'm not sure a UAC > is able to maximise the chances of a request succeeding at the same > time as minimising the risk of using weaker auth-schemes when stronger > ones may be supported. Perhaps the UAC should choose the strongest auth-scheme for each realm, and respond to all of those. That might fail on some fork if two alternate servers support different auth-schemes for the same realm. But that seems like a very badly configured realm, so maybe we don't care. Thanks, Paul From rifaat.ietf@gmail.com Sun Jan 26 03:28:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468681A0132 for ; Sun, 26 Jan 2014 03:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWGzYd1uF5MX for ; Sun, 26 Jan 2014 03:28:04 -0800 (PST) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5891A0131 for ; Sun, 26 Jan 2014 03:28:04 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id e53so1738470eek.39 for ; Sun, 26 Jan 2014 03:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rhpkSikmAbx4ncyTebsHY3oHCHRDlywccNoyPt0TXr0=; b=hyVtDU9V85bdArntziUZabSlEJ2AqYXTepG9pK7Dr8+2zz+8h4F7wdQtd/mONElR1E D3noehXTP2tB87Op4NsnS1yPcrZdKJwSRjG2YLYWzmaeOgAdNqlUbO2rRc4a8Y/Mr8Wq /91o07Op22DdT8aR/nkQYfvoXu9xQ6QycS79ww62bBtDt+dcDn3IbqhBbH/E/gXx8yS3 HSCtgpmPMDTc/yGJMZIFaw5CuYxuP66rWPiI9911Tq1fM/5DUbOQtMGYyuEo0fo13/eg TTtSN2coXnJ0UeDomuLVFR440vobmzknojmfE/dN/V4CAjTn+4f8DCxhc9zv7w3x/N5y IBQQ== MIME-Version: 1.0 X-Received: by 10.15.32.73 with SMTP id z49mr20554419eeu.27.1390735682309; Sun, 26 Jan 2014 03:28:02 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 26 Jan 2014 03:28:02 -0800 (PST) In-Reply-To: <52E42405.3070005@alum.mit.edu> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> <52E42405.3070005@alum.mit.edu> Date: Sun, 26 Jan 2014 06:28:02 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0160c5cc52146504f0dde2b5 Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 11:28:07 -0000 --089e0160c5cc52146504f0dde2b5 Content-Type: text/plain; charset=ISO-8859-1 Here is the current text from draft-yusef-sipcore-digest-scheme-04, section 2.4: When the UAC receives a response with multiple headers with the same realm it SHOULD use the topmost header that it supports, unless a local policy dictates otherwise. Which leaves it to the UAC's implementation to decide on what to do in different use cases. Is that good enough? should we change the SHOULD to MUST? Regards, Rifaat On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat wrote: > On 1/25/14 3:04 PM, Michael Procter wrote: > >> On 24 January 2014 23:05, Paul Kyzivat wrote: >> >>> On 1/24/14 5:14 PM, Dale R. Worley wrote: >>> >>>> It seems that in any of these cases, the UAC should provide >>>> credentials for every challenge for which it has matching credentials. >>>> Only if the UAC has no credentials for any of the challenges does the >>>> UAC know for certain that the resend will fail. >>>> >>> >>> Certainly it should respond to everything it can. >>> >> >> That seems to disagree with draft-ietf-httpauth-digest section 5.5 which >> begins: >> >> An HTTP/1.1 server may return multiple challenges with a 401 >> (Authenticate) response, and each challenge may use a different auth- >> scheme. A user agent MUST choose to use the strongest auth- scheme it >> understands and request credentials from the user based upon that >> challenge. >> >> If a UAS issues two challenges for the same realm but different >> auth-schemes, then it seems reasonable to only respond with the >> strongest supported auth-scheme. To respond with both a stronger and >> weaker algorithm seems unwise. >> >> But if a proxy aggregates two challenges for the same realm but with >> different auth-schemes, then as you both suggest, answering both >> challenges is most likely to succeed. RFC 3261 Section 22.3 last para >> addresses this scenario. >> >> Without being able to tell these two cases apart, I'm not sure a UAC >> is able to maximise the chances of a request succeeding at the same >> time as minimising the risk of using weaker auth-schemes when stronger >> ones may be supported. >> > > Perhaps the UAC should choose the strongest auth-scheme for each realm, > and respond to all of those. > > That might fail on some fork if two alternate servers support different > auth-schemes for the same realm. But that seems like a very badly > configured realm, so maybe we don't care. > > Thanks, > Paul > > --089e0160c5cc52146504f0dde2b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here is the current text from draft-yusef-sipcore-digest-s= cheme-04, section 2.4:
   When the UAC receives a response wit=
h multiple headers with the same
   realm it SHOULD use the topmost header that it supports, unless a
   local policy dictates otherwise.
Which leaves it to the = UAC's implementation to decide on what to do in different use cases.
Is that good enough? should we change the SHOULD to MUST?

Regards,
=A0Rifaat

<= br>




=


On Sat, Jan 2= 5, 2014 at 3:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= wrote:
On 1= /25/14 3:04 PM, Michael Procter wrote:
On 24 January 2014 23:05, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 1/24/14 5:14 PM, Dale R. Worley wrote:
It seems that in any of these cases, the UAC should provide
credentials for every challenge for which it has matching credentials.
Only if the UAC has no credentials for any of the challenges does the
UAC know for certain that the resend will fail.

Certainly it should respond to everything it can.

That seems to disagree with draft-ietf-httpauth-digest section 5.5 which be= gins:

=A0 =A0 An HTTP/1.1 server may return multiple challenges with a 401
=A0 =A0 (Authenticate) response, and each challenge may use a different aut= h-
=A0 =A0 scheme. A user agent MUST choose to use the strongest auth- scheme = it
=A0 =A0 understands and request credentials from the user based upon that =A0 =A0 challenge.

If a UAS issues two challenges for the same realm but different
auth-schemes, then it seems reasonable to only respond with the
strongest supported auth-scheme. =A0To respond with both a stronger and
weaker algorithm seems unwise.

But if a proxy aggregates two challenges for the same realm but with
different auth-schemes, then as you both suggest, answering both
challenges is most likely to succeed. =A0RFC 3261 Section 22.3 last para addresses this scenario.

Without being able to tell these two cases apart, I'm not sure a UAC is able to maximise the chances of a request succeeding at the same
time as minimising the risk of using weaker auth-schemes when stronger
ones may be supported.

Perhaps the UAC should choose the strongest auth-scheme for each realm, and= respond to all of those.

That might fail on some fork if two alternate servers support different aut= h-schemes for the same realm. But that seems like a very badly configured r= ealm, so maybe we don't care.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


--089e0160c5cc52146504f0dde2b5-- From pkyzivat@alum.mit.edu Sun Jan 26 11:15:10 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635E91A00F6 for ; Sun, 26 Jan 2014 11:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTkMBz1NxRSL for ; Sun, 26 Jan 2014 11:15:09 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id B02C71A00AE for ; Sun, 26 Jan 2014 11:15:08 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id JhoK1n0050vyq2s51jF6LJ; Sun, 26 Jan 2014 19:15:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id JjF51n0123ZTu2S3RjF5rT; Sun, 26 Jan 2014 19:15:06 +0000 Message-ID: <52E55EB9.2030104@alum.mit.edu> Date: Sun, 26 Jan 2014 14:15:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> <52E42405.3070005@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390763706; bh=DKxP7bA4dgLsj41hufJGmwuGg8Z9PEwYGp+ZYLAXeVs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=smfHIkSWgA+VCAOBJc8SZDMODDVtbQe0IqCOJ2bU5TdBkVfRLvgGNFfJK+RpbReId wz6dBPYtcV3+wZjiZW7lZZbcJBcihmBsKIG8X6HB5L3Kb9Fo1PpMug0JBODPrMBLMb on1wvBYJ+PfEg9XavbKPUddqZfGt+t0b++xYloLJKfP2hiC3L8TwTxIZFi4Jf9XPp7 NiayaBiofmVs57pnp0jiWprAHxLgVi4GlX3D0MJXF4ZH08ohOK2/SKiZqsS/V7Q0Vx DpzfZX7szJ9LrF9uNINso4qSkFBLdMekYZ4ieeAL+voWPqRhKz/IhP4PD1qGVxsCql kdD4YzItJMeOA== Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 19:15:10 -0000 On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote: > Here is the current text from draft-yusef-sipcore-digest-scheme-04, > section 2.4: > > When the UAC receives a response with multiple headers with the same > realm it SHOULD use the topmost header that it supports, unless a > local policy dictates otherwise. > > Which leaves it to the UAC's implementation to decide on what to do in > different use cases. > Is that good enough? should we change the SHOULD to MUST? If we are agreeing that the there should only be one response per realm, then the question is which one. The above says it SHOULD be the first one. In simple cases that is the one most preferred by the UAS. And if the UAS orders them strongest first, then it is equivalent to the UAC choosing the strongest. But it gets more complex with proxies and forking. Of note, how does a forking proxy merge these from different forks. Unless it determines the order of the merge based on strength, the first one may not be the strongest. ISTM that is is having too many cooks working on the soup. It seems clearer to just have the UAC choose the strongest it supports for each realm. Thanks, Paul > Regards, > Rifaat > > > > > > > > > On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat > wrote: > > On 1/25/14 3:04 PM, Michael Procter wrote: > > On 24 January 2014 23:05, Paul Kyzivat > wrote: > > On 1/24/14 5:14 PM, Dale R. Worley wrote: > > It seems that in any of these cases, the UAC should provide > credentials for every challenge for which it has > matching credentials. > Only if the UAC has no credentials for any of the > challenges does the > UAC know for certain that the resend will fail. > > > Certainly it should respond to everything it can. > > > That seems to disagree with draft-ietf-httpauth-digest section > 5.5 which begins: > > An HTTP/1.1 server may return multiple challenges with a 401 > (Authenticate) response, and each challenge may use a > different auth- > scheme. A user agent MUST choose to use the strongest auth- > scheme it > understands and request credentials from the user based > upon that > challenge. > > If a UAS issues two challenges for the same realm but different > auth-schemes, then it seems reasonable to only respond with the > strongest supported auth-scheme. To respond with both a > stronger and > weaker algorithm seems unwise. > > But if a proxy aggregates two challenges for the same realm but with > different auth-schemes, then as you both suggest, answering both > challenges is most likely to succeed. RFC 3261 Section 22.3 > last para > addresses this scenario. > > Without being able to tell these two cases apart, I'm not sure a UAC > is able to maximise the chances of a request succeeding at the same > time as minimising the risk of using weaker auth-schemes when > stronger > ones may be supported. > > > Perhaps the UAC should choose the strongest auth-scheme for each > realm, and respond to all of those. > > That might fail on some fork if two alternate servers support > different auth-schemes for the same realm. But that seems like a > very badly configured realm, so maybe we don't care. > > Thanks, > Paul > > From rifaat.ietf@gmail.com Sun Jan 26 11:45:12 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13B1A0096 for ; Sun, 26 Jan 2014 11:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGO0KLCbqf51 for ; Sun, 26 Jan 2014 11:45:09 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 491EA1A0093 for ; Sun, 26 Jan 2014 11:45:09 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id f15so1350656eak.16 for ; Sun, 26 Jan 2014 11:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3IMCYtdkLp6xDTBELvbG97ZAAQ1pQ323DznlPnhcgT8=; b=wJHtMHpQly0N35e95axRCfEAhM6efNpBOADXiRQKH4/QWPurL0pqejLuLWxHH++IV6 f3Q+JOMIhvTrM9Oca81hgC3HSLztjuPMW0xayxb2xys99GUro46h6sdwixAj60eN+6KF MgPCy05Hu+gNbxazoPLCWatJrlBvaC14d5ocVri/5ayXrPujngbO+1FRo6ep7X8uw8Pd 5iN4QZjL/xEPeBruKheGSKTxAtm779Uwy/N9YZTtdeLYqWturR6/Jp72iw3J9ztA4non bEOfssIM5B8iWXBwQgCe3EW7p8E4KENHR+txzu//U+qHvSgf/68fubQR3EdIgR2giQ4x t/ig== MIME-Version: 1.0 X-Received: by 10.14.201.68 with SMTP id a44mr21895496eeo.46.1390765506728; Sun, 26 Jan 2014 11:45:06 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 26 Jan 2014 11:45:06 -0800 (PST) In-Reply-To: <52E55EB9.2030104@alum.mit.edu> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> <52E42405.3070005@alum.mit.edu> <52E55EB9.2030104@alum.mit.edu> Date: Sun, 26 Jan 2014 14:45:06 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b343518fe97dc04f0e4d380 Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 19:45:12 -0000 --047d7b343518fe97dc04f0e4d380 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat wrote: > On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote: > >> Here is the current text from draft-yusef-sipcore-digest-scheme-04, >> section 2.4: >> >> When the UAC receives a response with multiple headers with the same >> realm it SHOULD use the topmost header that it supports, unless a >> local policy dictates otherwise. >> >> Which leaves it to the UAC's implementation to decide on what to do in >> different use cases. >> Is that good enough? should we change the SHOULD to MUST? >> > > If we are agreeing that the there should only be one response per realm, > then the question is which one. > > The above says it SHOULD be the first one. In simple cases that is the one > most preferred by the UAS. And if the UAS orders them strongest first, then > it is equivalent to the UAC choosing the strongest. > > The reason for doing that in the HTTP draft was to minimize the impact on the browsers, as the existing behavior of the browsers is to prefer the topmost header. > But it gets more complex with proxies and forking. Of note, how does a > forking proxy merge these from different forks. Unless it determines the > order of the merge based on strength, the first one may not be the > strongest. > > Do you see a problem with requiring proxies to order them based on strength? > ISTM that is is having too many cooks working on the soup. It seems > clearer to just have the UAC choose the strongest it supports for each > realm. > > The question is: how will existing UACs behave when they receive multiple headers? Will they choke? Will they prefer the first? the last? Regards, Rifaat > Thanks, > Paul > > Regards, >> Rifaat >> >> >> >> >> >> >> >> >> On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat > > wrote: >> >> On 1/25/14 3:04 PM, Michael Procter wrote: >> >> On 24 January 2014 23:05, Paul Kyzivat > > wrote: >> >> On 1/24/14 5:14 PM, Dale R. Worley wrote: >> >> It seems that in any of these cases, the UAC should >> provide >> credentials for every challenge for which it has >> matching credentials. >> Only if the UAC has no credentials for any of the >> challenges does the >> UAC know for certain that the resend will fail. >> >> >> Certainly it should respond to everything it can. >> >> >> That seems to disagree with draft-ietf-httpauth-digest section >> 5.5 which begins: >> >> An HTTP/1.1 server may return multiple challenges with a 401 >> (Authenticate) response, and each challenge may use a >> different auth- >> scheme. A user agent MUST choose to use the strongest auth- >> scheme it >> understands and request credentials from the user based >> upon that >> challenge. >> >> If a UAS issues two challenges for the same realm but different >> auth-schemes, then it seems reasonable to only respond with the >> strongest supported auth-scheme. To respond with both a >> stronger and >> weaker algorithm seems unwise. >> >> But if a proxy aggregates two challenges for the same realm but >> with >> different auth-schemes, then as you both suggest, answering both >> challenges is most likely to succeed. RFC 3261 Section 22.3 >> last para >> addresses this scenario. >> >> Without being able to tell these two cases apart, I'm not sure a >> UAC >> is able to maximise the chances of a request succeeding at the >> same >> time as minimising the risk of using weaker auth-schemes when >> stronger >> ones may be supported. >> >> >> Perhaps the UAC should choose the strongest auth-scheme for each >> realm, and respond to all of those. >> >> That might fail on some fork if two alternate servers support >> different auth-schemes for the same realm. But that seems like a >> very badly configured realm, so maybe we don't care. >> >> Thanks, >> Paul >> >> >> > --047d7b343518fe97dc04f0e4d380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 1/26/14 6:28 AM, Rifaat= Shekh-Yusef wrote:
Here is the current text from draft-yusef-sipcore-digest-scheme-04,<= br> section 2.4:

=A0 =A0 When the UAC receives a response with multiple headers with the sam= e
=A0 =A0 realm it SHOULD use the topmost header that it supports, unless a =A0 =A0 local policy dictates otherwise.

Which leaves it to the UAC's implementation to decide on what to do in<= br> different use cases.
Is that good enough? should we change the SHOULD to MUST?

If we are agreeing that the there should only be one response per realm, th= en the question is which one.

The above says it SHOULD be the first one. In simple cases that is the one = most preferred by the UAS. And if the UAS orders them strongest first, then= it is equivalent to the UAC choosing the strongest.


The reason for doing that in the HTTP = draft was to minimize the impact on the browsers, as the existing behavior = of the browsers is to prefer the topmost header.

=A0
But it gets more complex with proxies and forking. Of note, how does a fork= ing proxy merge these from different forks. Unless it determines the order = of the merge based on strength, the first one may not be the strongest.


Do you see a problem with requiring pr= oxies to order them based on strength?

=A0
ISTM that is is having too many cooks working on the soup. It seems clearer= to just have the UAC choose the strongest it supports for each realm.


The question is: how will existing UAC= s behave when they receive multiple headers?
Will they choke?=
Will they prefer the first? the last?

Regards,
=A0Rifaat



=A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Regards,
=A0 Rifaat








On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 On 1/25/14 3:04 PM, Michael Procter wrote:

=A0 =A0 =A0 =A0 On 24 January 2014 23:05, Paul Kyzivat <pkyzivat@alum.mit.edu
=A0 =A0 =A0 =A0 <mailto:pkyzivat@alum.mit.edu>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 On 1/24/14 5:14 PM, Dale R. Worley wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It seems that in any of these cases, the UA= C should provide
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 credentials for every challenge for which i= t has
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 matching credentials.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Only if the UAC has no credentials for any = of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 challenges does the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UAC know for certain that the resend will f= ail.


=A0 =A0 =A0 =A0 =A0 =A0 Certainly it should respond to everything it can.

=A0 =A0 =A0 =A0 That seems to disagree with draft-ietf-httpauth-digest sect= ion
=A0 =A0 =A0 =A0 5.5 which begins:

=A0 =A0 =A0 =A0 =A0 =A0 =A0An HTTP/1.1 server may return multiple challenge= s with a 401
=A0 =A0 =A0 =A0 =A0 =A0 =A0(Authenticate) response, and each challenge may = use a
=A0 =A0 =A0 =A0 different auth-
=A0 =A0 =A0 =A0 =A0 =A0 =A0scheme. A user agent MUST choose to use the stro= ngest auth-
=A0 =A0 =A0 =A0 scheme it
=A0 =A0 =A0 =A0 =A0 =A0 =A0understands and request credentials from the use= r based
=A0 =A0 =A0 =A0 upon that
=A0 =A0 =A0 =A0 =A0 =A0 =A0challenge.

=A0 =A0 =A0 =A0 If a UAS issues two challenges for the same realm but diffe= rent
=A0 =A0 =A0 =A0 auth-schemes, then it seems reasonable to only respond with= the
=A0 =A0 =A0 =A0 strongest supported auth-scheme. =A0To respond with both a<= br> =A0 =A0 =A0 =A0 stronger and
=A0 =A0 =A0 =A0 weaker algorithm seems unwise.

=A0 =A0 =A0 =A0 But if a proxy aggregates two challenges for the same realm= but with
=A0 =A0 =A0 =A0 different auth-schemes, then as you both suggest, answering= both
=A0 =A0 =A0 =A0 challenges is most likely to succeed. =A0RFC 3261 Section 2= 2.3
=A0 =A0 =A0 =A0 last para
=A0 =A0 =A0 =A0 addresses this scenario.

=A0 =A0 =A0 =A0 Without being able to tell these two cases apart, I'm n= ot sure a UAC
=A0 =A0 =A0 =A0 is able to maximise the chances of a request succeeding at = the same
=A0 =A0 =A0 =A0 time as minimising the risk of using weaker auth-schemes wh= en
=A0 =A0 =A0 =A0 stronger
=A0 =A0 =A0 =A0 ones may be supported.


=A0 =A0 Perhaps the UAC should choose the strongest auth-scheme for each =A0 =A0 realm, and respond to all of those.

=A0 =A0 That might fail on some fork if two alternate servers support
=A0 =A0 different auth-schemes for the same realm. But that seems like a =A0 =A0 very badly configured realm, so maybe we don't care.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul




--047d7b343518fe97dc04f0e4d380-- From pkyzivat@alum.mit.edu Sun Jan 26 12:40:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F161A004B for ; Sun, 26 Jan 2014 12:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak79iXNdaC6K for ; Sun, 26 Jan 2014 12:40:07 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id C9E861A0034 for ; Sun, 26 Jan 2014 12:40:06 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id JjjR1n0011ei1Bg59kg4DW; Sun, 26 Jan 2014 20:40:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Jkg31n00Y3ZTu2S3kkg3DD; Sun, 26 Jan 2014 20:40:04 +0000 Message-ID: <52E572A3.4090905@alum.mit.edu> Date: Sun, 26 Jan 2014 15:40:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> <52E42405.3070005@alum.mit.edu> <52E55EB9.2030104@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390768804; bh=aMWf0EY005OIQXCl71q+Yme4n0B1IOF8aIqp5VXzACs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V/jCM8kvsi9I09rdi145mF3lmxY6xofLmoyZYw3CVo/qWj15+enyO3Qm8goOssDqq wvtT8QiSOJi2dx69/g+9SQFtKHU18WFDg7r0ZQIzYnBdJUyRAOiVTBENGKS7+/Av1S 4YGNPuHccCoEqzg9xu3TGD/XuDYih4vM0VADLEmLIR/ENJ7WDcprUccaQ2Pwi8b7sJ Lmp9+HTr8w8Bojace6qiLHrGub0J2zPxVZ5hNaiU5e9wFzOuTBrbr7uFR3B/NVkASV 0WfROdoQ2uO8IsEU2TYK+sFps4vgfDPvyIWf5KYpNm46sye0ue4fDXkp01y3KpfHuC R71EDOhDU/+EA== Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 20:40:08 -0000 On 1/26/14 2:45 PM, Rifaat Shekh-Yusef wrote: > > > > On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat > wrote: > > On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote: > > Here is the current text from > draft-yusef-sipcore-digest-__scheme-04, > section 2.4: > > When the UAC receives a response with multiple headers with > the same > realm it SHOULD use the topmost header that it supports, > unless a > local policy dictates otherwise. > > Which leaves it to the UAC's implementation to decide on what to > do in > different use cases. > Is that good enough? should we change the SHOULD to MUST? > > > If we are agreeing that the there should only be one response per > realm, then the question is which one. > > The above says it SHOULD be the first one. In simple cases that is > the one most preferred by the UAS. And if the UAS orders them > strongest first, then it is equivalent to the UAC choosing the > strongest. > > > The reason for doing that in the HTTP draft was to minimize the impact > on the browsers, as the existing behavior of the browsers is to prefer > the topmost header. Well, that is fine for browsers. What is existing behavior for sip UACs? Maybe we can't depend on common language for this. > But it gets more complex with proxies and forking. Of note, how does > a forking proxy merge these from different forks. Unless it > determines the order of the merge based on strength, the first one > may not be the strongest. > > > Do you see a problem with requiring proxies to order them based on strength? Note that afaik this is only a sip problem. I don't think there are forking proxies for http. In principle it could be done in proxies. But do you want to depend on all affected proxies implementing this? The UAC and UAS *need* to implement this before they can use new algorithms. Once they do, most things may work with existing proxies if you don't put such a requirement on them. > ISTM that is is having too many cooks working on the soup. It seems > clearer to just have the UAC choose the strongest it supports for > each realm. > > > The question is: how will existing UACs behave when they receive > multiple headers? > Will they choke? > Will they prefer the first? the last? Yes, that is an important question. They *shouldn't* choke, because they can already get this. Are they going to choke when they see a new algorithm mentioned? I can imagine that testing may show that you can get backward compatible behavior best when the UAS puts the md5 algorithm first. Then implementations compatible with your draft, that support other algorithms, can pick out the strongest that they support. But this is something we might want data on before making a decision. Thanks, Paul > Regards, > Rifaat > > > > Thanks, > Paul > > Regards, > Rifaat > > > > > > > > > On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat > > >__> > wrote: > > On 1/25/14 3:04 PM, Michael Procter wrote: > > On 24 January 2014 23:05, Paul Kyzivat > > >__> wrote: > > On 1/24/14 5:14 PM, Dale R. Worley wrote: > > It seems that in any of these cases, the UAC > should provide > credentials for every challenge for which it has > matching credentials. > Only if the UAC has no credentials for any of the > challenges does the > UAC know for certain that the resend will fail. > > > Certainly it should respond to everything it can. > > > That seems to disagree with draft-ietf-httpauth-digest > section > 5.5 which begins: > > An HTTP/1.1 server may return multiple challenges > with a 401 > (Authenticate) response, and each challenge may use a > different auth- > scheme. A user agent MUST choose to use the > strongest auth- > scheme it > understands and request credentials from the user > based > upon that > challenge. > > If a UAS issues two challenges for the same realm but > different > auth-schemes, then it seems reasonable to only respond > with the > strongest supported auth-scheme. To respond with both a > stronger and > weaker algorithm seems unwise. > > But if a proxy aggregates two challenges for the same > realm but with > different auth-schemes, then as you both suggest, > answering both > challenges is most likely to succeed. RFC 3261 Section > 22.3 > last para > addresses this scenario. > > Without being able to tell these two cases apart, I'm > not sure a UAC > is able to maximise the chances of a request succeeding > at the same > time as minimising the risk of using weaker > auth-schemes when > stronger > ones may be supported. > > > Perhaps the UAC should choose the strongest auth-scheme for > each > realm, and respond to all of those. > > That might fail on some fork if two alternate servers support > different auth-schemes for the same realm. But that seems > like a > very badly configured realm, so maybe we don't care. > > Thanks, > Paul > > > > From rifaat.ietf@gmail.com Sun Jan 26 14:41:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE2A1A0090 for ; Sun, 26 Jan 2014 14:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSQvKdjq_LnS for ; Sun, 26 Jan 2014 14:41:13 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A68AD1A0060 for ; Sun, 26 Jan 2014 14:41:12 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id e49so1949324eek.0 for ; Sun, 26 Jan 2014 14:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fyhrkfa5b5ofE7yCbUP4tsAd1iCcJ/hL3qzf71wraxA=; b=ii8iwpOIJAec/ohM6I+vyTLfilwiHYRs6xjP17lGCM11rHewwxK8F55iLxU5gGeiMx r1ZEsfWorZOemv03gweDwGpJKYZIc4EhQc6cWz98dPCi9ImmkXgi/9bBRJHEp7+zhSUu GdeAuBSuDaswnX6VFmRjo96S8CnbfyhYDG95xVgeXGc2gKyVvwu5GCFIVOs9OkYIszA0 Jb+vynuqqRf8wsYXH8uSg2Yxm6Z/uMqVCvWYDeaz2un4TXzGZYLVQ94xItM4RXl3t4pg qi9mv6U6Q1QDMYFxkMvKDdZq13li+3b5eCG8PmrVS97yP+l8YmKaJIEfQ9Cy5L87jmlO qS3w== MIME-Version: 1.0 X-Received: by 10.15.43.10 with SMTP id w10mr22427742eev.13.1390776070032; Sun, 26 Jan 2014 14:41:10 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 26 Jan 2014 14:41:09 -0800 (PST) In-Reply-To: <52E572A3.4090905@alum.mit.edu> References: <201401232248.s0NMmJkZ3445035@shell01.TheWorld.com> <52E1DCEE.4020007@alum.mit.edu> <52E29675.3030004@alum.mit.edu> <201401242214.s0OMEvwU3517611@shell01.TheWorld.com> <52E2F1B2.5060702@alum.mit.edu> <52E42405.3070005@alum.mit.edu> <52E55EB9.2030104@alum.mit.edu> <52E572A3.4090905@alum.mit.edu> Date: Sun, 26 Jan 2014 17:41:09 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e016816449dd0e704f0e74962 Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 22:41:16 -0000 --089e016816449dd0e704f0e74962 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 26, 2014 at 3:40 PM, Paul Kyzivat wrote: > On 1/26/14 2:45 PM, Rifaat Shekh-Yusef wrote: > >> >> >> >> On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat > > wrote: >> >> On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote: >> >> Here is the current text from >> draft-yusef-sipcore-digest-__scheme-04, >> >> section 2.4: >> >> When the UAC receives a response with multiple headers with >> the same >> realm it SHOULD use the topmost header that it supports, >> unless a >> local policy dictates otherwise. >> >> Which leaves it to the UAC's implementation to decide on what to >> do in >> different use cases. >> Is that good enough? should we change the SHOULD to MUST? >> >> >> If we are agreeing that the there should only be one response per >> realm, then the question is which one. >> >> The above says it SHOULD be the first one. In simple cases that is >> the one most preferred by the UAS. And if the UAS orders them >> strongest first, then it is equivalent to the UAC choosing the >> strongest. >> >> >> The reason for doing that in the HTTP draft was to minimize the impact >> on the browsers, as the existing behavior of the browsers is to prefer >> the topmost header. >> > > Well, that is fine for browsers. What is existing behavior for sip UACs? > Maybe we can't depend on common language for this. > > Yes, I agree; the recommendation for SIP will most likely be different than the recommendations for HTTP. > > But it gets more complex with proxies and forking. Of note, how does >> a forking proxy merge these from different forks. Unless it >> determines the order of the merge based on strength, the first one >> may not be the strongest. >> >> >> Do you see a problem with requiring proxies to order them based on >> strength? >> > > Note that afaik this is only a sip problem. I don't think there are > forking proxies for http. > > In principle it could be done in proxies. But do you want to depend on all > affected proxies implementing this? The UAC and UAS *need* to implement > this before they can use new algorithms. Once they do, most things may work > with existing proxies if you don't put such a requirement on them. > > Yeah, that will complicate things. > > ISTM that is is having too many cooks working on the soup. It seems >> clearer to just have the UAC choose the strongest it supports for >> each realm. >> >> >> The question is: how will existing UACs behave when they receive >> multiple headers? >> Will they choke? >> Will they prefer the first? the last? >> > > Yes, that is an important question. They *shouldn't* choke, because they > can already get this. Are they going to choke when they see a new algorithm > mentioned? > > I can imagine that testing may show that you can get backward compatible > behavior best when the UAS puts the md5 algorithm first. Then > implementations compatible with your draft, that support other algorithms, > can pick out the strongest that they support. > > But this is something we might want data on before making a decision. > > Agree, Regards. Rifaat > Thanks, > Paul > > Regards, >> Rifaat >> >> >> >> Thanks, >> Paul >> >> Regards, >> Rifaat >> >> >> >> >> >> >> >> >> On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat >> >> >__> >> >> wrote: >> >> On 1/25/14 3:04 PM, Michael Procter wrote: >> >> On 24 January 2014 23:05, Paul Kyzivat >> >> > >> >__> wrote: >> >> On 1/24/14 5:14 PM, Dale R. Worley wrote: >> >> It seems that in any of these cases, the UAC >> should provide >> credentials for every challenge for which it has >> matching credentials. >> Only if the UAC has no credentials for any of the >> challenges does the >> UAC know for certain that the resend will fail. >> >> >> Certainly it should respond to everything it can. >> >> >> That seems to disagree with draft-ietf-httpauth-digest >> section >> 5.5 which begins: >> >> An HTTP/1.1 server may return multiple challenges >> with a 401 >> (Authenticate) response, and each challenge may use >> a >> different auth- >> scheme. A user agent MUST choose to use the >> strongest auth- >> scheme it >> understands and request credentials from the user >> based >> upon that >> challenge. >> >> If a UAS issues two challenges for the same realm but >> different >> auth-schemes, then it seems reasonable to only respond >> with the >> strongest supported auth-scheme. To respond with both a >> stronger and >> weaker algorithm seems unwise. >> >> But if a proxy aggregates two challenges for the same >> realm but with >> different auth-schemes, then as you both suggest, >> answering both >> challenges is most likely to succeed. RFC 3261 Section >> 22.3 >> last para >> addresses this scenario. >> >> Without being able to tell these two cases apart, I'm >> not sure a UAC >> is able to maximise the chances of a request succeeding >> at the same >> time as minimising the risk of using weaker >> auth-schemes when >> stronger >> ones may be supported. >> >> >> Perhaps the UAC should choose the strongest auth-scheme for >> each >> realm, and respond to all of those. >> >> That might fail on some fork if two alternate servers support >> different auth-schemes for the same realm. But that seems >> like a >> very badly configured realm, so maybe we don't care. >> >> Thanks, >> Paul >> >> >> >> >> > --089e016816449dd0e704f0e74962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Jan 26, 2014 at 3:40 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 1/26/14 2:45 PM, Rifaat Shekh-Yusef w= rote:



On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote:

=A0 =A0 =A0 =A0 Here is the current text from
=A0 =A0 =A0 =A0 draft-yusef-sipcore-digest-__scheme-04,

=A0 =A0 =A0 =A0 section 2.4:

=A0 =A0 =A0 =A0 =A0 =A0 =A0When the UAC receives a response with multiple h= eaders with
=A0 =A0 =A0 =A0 the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0realm it SHOULD use the topmost header that it s= upports,
=A0 =A0 =A0 =A0 unless a
=A0 =A0 =A0 =A0 =A0 =A0 =A0local policy dictates otherwise.

=A0 =A0 =A0 =A0 Which leaves it to the UAC's implementation to decide o= n what to
=A0 =A0 =A0 =A0 do in
=A0 =A0 =A0 =A0 different use cases.
=A0 =A0 =A0 =A0 Is that good enough? should we change the SHOULD to MUST?

=A0 =A0 If we are agreeing that the there should only be one response per =A0 =A0 realm, then the question is which one.

=A0 =A0 The above says it SHOULD be the first one. In simple cases that is<= br> =A0 =A0 the one most preferred by the UAS. And if the UAS orders them
=A0 =A0 strongest first, then it is equivalent to the UAC choosing the
=A0 =A0 strongest.


The reason for doing that in the HTTP draft was to minimize the impact
on the browsers, as the existing behavior of the browsers is to prefer
the topmost header.

Well, that is fine for browsers. What is existing behavior for sip UACs? Maybe we can't depend on common language for this.

Yes, I agree; the recommendation fo= r SIP will most likely be different than the=A0=A0recommendations for HTTP.=

=A0

=A0 =A0 But it gets more complex with proxies and forking. Of note, how doe= s
=A0 =A0 a forking proxy merge these from different forks. Unless it
=A0 =A0 determines the order of the merge based on strength, the first one<= br> =A0 =A0 may not be the strongest.


Do you see a problem with requiring proxies to order them based on strength= ?

Note that afaik this is only a sip problem. I don't think there are for= king proxies for http.

In principle it could be done in proxies. But do you want to depend on all = affected proxies implementing this? The UAC and UAS *need* to implement thi= s before they can use new algorithms. Once they do, most things may work wi= th existing proxies if you don't put such a requirement on them.


Yeah, that will complicate thing= s.

=A0

=A0 =A0 ISTM that is is having too many cooks working on the soup. It seems=
=A0 =A0 clearer to just have the UAC choose the strongest it supports for =A0 =A0 each realm.


The question is: how will existing UACs behave when they receive
multiple headers?
Will they choke?
Will they prefer the first? the last?

Yes, that is an important question. They *shouldn't* choke, because the= y can already get this. Are they going to choke when they see a new algorit= hm mentioned?

I can imagine that testing may show that you can get backward compatible be= havior best when the UAS puts the md5 algorithm first. Then implementations= compatible with your draft, that support other algorithms, can pick out th= e strongest that they support.

But this is something we might want data on before making a decision.


Agree,


Regards.
=A0Rifaat
=A0
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Regards,
=A0 Rifaat



=A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0Rifaat








=A0 =A0 =A0 =A0 On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat
=A0 =A0 =A0 =A0 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
=A0 =A0 =A0 =A0 <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>__= >

=A0 =A0 =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0On 1/25/14 3:04 PM, Michael Procter wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 24 January 2014 23:05, Paul Kyzivat =A0 =A0 =A0 =A0 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:pkyzivat@alum.mit.edu

=A0 =A0 =A0 =A0 <mailto:pkyzivat@alum.mit.edu>>__> wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 1/24/14 5:14 PM, Dale R. Worl= ey wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It seems that in any of = these cases, the UAC
=A0 =A0 =A0 =A0 should provide
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0credentials for every ch= allenge for which it has
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matching credentials. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Only if the UAC has no c= redentials for any of the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0challenges does the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0UAC know for certain tha= t the resend will fail.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Certainly it should respond to e= verything it can.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That seems to disagree with draft-ietf-h= ttpauth-digest
=A0 =A0 =A0 =A0 section
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A05.5 which begins:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 An HTTP/1.1 server may return m= ultiple challenges
=A0 =A0 =A0 =A0 with a 401
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Authenticate) response, and ea= ch challenge may use a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0different auth-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 scheme. A user agent MUST choos= e to use the
=A0 =A0 =A0 =A0 strongest auth-
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0scheme it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 understands and request credent= ials from the user
=A0 =A0 =A0 =A0 based
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0upon that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 challenge.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If a UAS issues two challenges for the s= ame realm but
=A0 =A0 =A0 =A0 different
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0auth-schemes, then it seems reasonable t= o only respond
=A0 =A0 =A0 =A0 with the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strongest supported auth-scheme. =A0To r= espond with both a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stronger and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0weaker algorithm seems unwise.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0But if a proxy aggregates two challenges= for the same
=A0 =A0 =A0 =A0 realm but with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0different auth-schemes, then as you both= suggest,
=A0 =A0 =A0 =A0 answering both
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0challenges is most likely to succeed. = =A0RFC 3261 Section
=A0 =A0 =A0 =A0 22.3
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0last para
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addresses this scenario.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Without being able to tell these two cas= es apart, I'm
=A0 =A0 =A0 =A0 not sure a UAC
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is able to maximise the chances of a req= uest succeeding
=A0 =A0 =A0 =A0 at the same
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0time as minimising the risk of using wea= ker
=A0 =A0 =A0 =A0 auth-schemes when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stronger
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ones may be supported.


=A0 =A0 =A0 =A0 =A0 =A0 =A0Perhaps the UAC should choose the strongest auth= -scheme for
=A0 =A0 =A0 =A0 each
=A0 =A0 =A0 =A0 =A0 =A0 =A0realm, and respond to all of those.

=A0 =A0 =A0 =A0 =A0 =A0 =A0That might fail on some fork if two alternate se= rvers support
=A0 =A0 =A0 =A0 =A0 =A0 =A0different auth-schemes for the same realm. But t= hat seems
=A0 =A0 =A0 =A0 like a
=A0 =A0 =A0 =A0 =A0 =A0 =A0very badly configured realm, so maybe we don'= ;t care.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul






--089e016816449dd0e704f0e74962-- From worley@shell01.TheWorld.com Tue Jan 28 10:21:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6A1A035A for ; Tue, 28 Jan 2014 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX68TE4bqR3C for ; Tue, 28 Jan 2014 10:21:10 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4A1A0356 for ; Tue, 28 Jan 2014 10:21:09 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s0SIK7Hx013679 for ; Tue, 28 Jan 2014 13:20:09 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s0SICnCg3780002 for ; Tue, 28 Jan 2014 13:12:49 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s0SICmND3782203; Tue, 28 Jan 2014 13:12:48 -0500 (EST) Date: Tue, 28 Jan 2014 13:12:48 -0500 (EST) Message-Id: <201401281812.s0SICmND3782203@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (rifaat.ietf@gmail.com) References: <20140125134253.20916.76333.idtracker@ietfa.amsl.com> Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 18:21:13 -0000 > From: Rifaat Shekh-Yusef > Are there SIP servers and clients out there that support *only* RFC > 2069 that would break because of this? The open-source sipX didn't support qop a few years ago. I don't know which of its derivatives do now. The one that eZuce sponsors does support qop. > From: Michael Procter > Without being able to tell these two cases apart, I'm not sure a UAC > is able to maximise the chances of a request succeeding at the same > time as minimising the risk of using weaker auth-schemes when stronger > ones may be supported. That seems to be an unavoidable tradeoff. Dale From pkyzivat@alum.mit.edu Tue Jan 28 12:47:49 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437DD1A027B for ; Tue, 28 Jan 2014 12:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1e5J1aGQwqZ for ; Tue, 28 Jan 2014 12:47:48 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id EFB4E1A001E for ; Tue, 28 Jan 2014 12:47:47 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id KXAh1n0010Fqzac56YnlVn; Tue, 28 Jan 2014 20:47:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id KYnk1n00W3ZTu2S3UYnlbC; Tue, 28 Jan 2014 20:47:45 +0000 Message-ID: <52E81770.8040801@alum.mit.edu> Date: Tue, 28 Jan 2014 15:47:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140125134253.20916.76333.idtracker@ietfa.amsl.com> <201401281812.s0SICmND3782203@shell01.TheWorld.com> In-Reply-To: <201401281812.s0SICmND3782203@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390942065; bh=WUiJBbcLqSQCnf2VHg2v+lB1qdUIyeNUb1MSm8G3HeQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TZ4vIPZyQkYFrK7/56pEhJJP68o7IOHlAi2fNPPYW5ICdB93yr8pIFgPhsNIwJD4b rtUfM5XSND5SpRfNRoJ7R4feNesi7vl3Mmkc4NYO7e3jTyhCWx5wUBwx+LivnT8B14 /3veqoCHvy/uYxEVOntZ91hDXWY22DVbo/shVvNni4km/efqYGb7faKfKp+fHbZbPk 42d2IsqSnKaao3NiyTsBz2wU2hqOH3uUghG1Mr74MVMkXPWAU02Xcqo3RXIAPoIWbE SXL6z5wR7YnIXqjETecLkdsAoCt56WnFagxCaB9/oMUT8TL4kRfpXpWAWqeOtk6V2i x3aAES8nPzK5g== Subject: Re: [sipcore] New Version Notification for draft-yusef-sipcore-digest-scheme-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:47:49 -0000 On 1/28/14 1:12 PM, Dale R. Worley wrote: >> From: Rifaat Shekh-Yusef > >> Are there SIP servers and clients out there that support *only* RFC >> 2069 that would break because of this? > > The open-source sipX didn't support qop a few years ago. I don't know > which of its derivatives do now. The one that eZuce sponsors does > support qop. > >> From: Michael Procter > >> Without being able to tell these two cases apart, I'm not sure a UAC >> is able to maximise the chances of a request succeeding at the same >> time as minimising the risk of using weaker auth-schemes when stronger >> ones may be supported. > > That seems to be an unavoidable tradeoff. The best I can see is for the UAC to respond to the strongest algorithm for each realm. That is a problem if a single realm has some servers with weaker support than others. But the realm ought to fix that. Thanks, Paul From wwwrun@rfc-editor.org Wed Jan 29 09:31:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA99A1A037E; Wed, 29 Jan 2014 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anzfrRFHBm23; Wed, 29 Jan 2014 09:31:05 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 48E291A0355; Wed, 29 Jan 2014 09:31:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D3EAE7FC39C; Wed, 29 Jan 2014 09:31:00 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140129173100.D3EAE7FC39C@rfc-editor.org> Date: Wed, 29 Jan 2014 09:31:00 -0800 (PST) Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7118 on The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 17:31:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7118 Title: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) Author: I. Baz Castillo, J. Millan Villegas, V. Pascual Status: Standards Track Stream: IETF Date: January 2014 Mailbox: ibc@aliax.net, jmillan@aliax.net, victor.pascual@quobis.com Pages: 25 Characters: 51248 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-sip-websocket-10.txt URL: http://www.rfc-editor.org/rfc/rfc7118.txt The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ibc@aliax.net Wed Jan 29 10:14:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C321A02F2 for ; Wed, 29 Jan 2014 10:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AssIQZrOonwy for ; Wed, 29 Jan 2014 10:14:04 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 787561A0276 for ; Wed, 29 Jan 2014 10:14:04 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i8so3287986qcq.18 for ; Wed, 29 Jan 2014 10:14:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=N3sJQyXJibN5vU32t9V3+02rOPQlJP6wE+BlfzlOBsg=; b=flZf0qv6XBoxoqTEaBeACTlKR3BFRD2NXz/VMfdOjJLdWSlvOYlT/v9wTv4hZwr3in 9fF2mBPn0oHqnKQVAi17EjP6ONCsELHOp4sra1yY+H1MVuW4KbpaUY25iobZGFy0yviX XU5Jf4dARP+WwPsYYGcNSFjZXOjnq8x2R9aolINGq1/cChdCg4rQc4HQXPcB0CKFGeTm lY5SFHbrbC7pLeajnVUqFDdqiLLQJaT+g1wWzLXiYxie4KTkiR/dM7VzVxf6DBNGWMnV +1PiPXKt6dNin6ZxGQZDm4rJJfDpp8OS26Jk1WsTuxL113S5FF4uMHsCP59pW1WtyT9L r5mQ== X-Gm-Message-State: ALoCoQnBsluldEWXnvAfHDlfLMuvXGJim5zgbIGcPIagWUpISOYUrzaXVbtaXdB8LQlPllf84XEn X-Received: by 10.224.72.11 with SMTP id k11mr747887qaj.91.1391019241175; Wed, 29 Jan 2014 10:14:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.101.232 with HTTP; Wed, 29 Jan 2014 10:13:41 -0800 (PST) In-Reply-To: <20140129173100.D3EAE7FC39C@rfc-editor.org> References: <20140129173100.D3EAE7FC39C@rfc-editor.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 29 Jan 2014 19:13:41 +0100 Message-ID: To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: drafts-update-ref@iana.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , rfc-dist@rfc-editor.org, ietf-announce@ietf.org Subject: Re: [sipcore] RFC 7118 on The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 18:14:06 -0000 Really thanks a lot to all of you for your work and feedback during all this time. Best regards. 2014-01-29 : > A new Request for Comments is now available in online RFC libraries. > > > RFC 7118 > > Title: The WebSocket Protocol as a Transport > for the Session Initiation Protocol (SIP) > Author: I. Baz Castillo, J. Millan Villegas, > V. Pascual > Status: Standards Track > Stream: IETF > Date: January 2014 > Mailbox: ibc@aliax.net, > jmillan@aliax.net, > victor.pascual@quobis.com > Pages: 25 > Characters: 51248 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-sipcore-sip-websocket-10.txt > > URL: http://www.rfc-editor.org/rfc/rfc7118.txt > > The WebSocket protocol enables two-way real-time communication > between clients and servers in web-based applications. This document > specifies a WebSocket subprotocol as a reliable transport mechanism > between Session Initiation Protocol (SIP) entities to enable use of > SIP in web-oriented deployments. > > This document is a product of the Session Initiation Protocol Core Workin= g Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestio= ns > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_se= arch.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Fri Jan 31 02:50:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E81A0587 for ; Fri, 31 Jan 2014 02:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DjD7zpuSXXg for ; Fri, 31 Jan 2014 02:50:05 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 1F89E1A057D for ; Fri, 31 Jan 2014 02:50:04 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 93C4E93C2A2; Fri, 31 Jan 2014 10:49:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" Date: Fri, 31 Jan 2014 11:49:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140131103332.20693.37687.idtracker@ietfa.amsl.com> To: SIPCORE WG X-Mailer: Apple Mail (2.1827) Cc: Olle E Johansson Subject: [sipcore] Fwd: New Version Notification for draft-johansson-sip-dual-stack-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 10:50:07 -0000 Hi! We have updated the draft to reflect the feedback we got on the list. = Changes are as follows: - Removed "Updates: 3263" from header - Cleaned up text throughout the document to clarify the scope and = intent (not to invalidate 3263-compliant implementations) - added some TODO's based on recent comments requiring follow-up - Slight updates to Security Considerations and Acknowledgments - Broke Terminology and Conventions section into two separate sections As you see we still have a todo, but we do think this is a good platform = for further discussions in SIPcore. Best regards, /Olle & Gonzalo Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-johansson-sip-dual-stack-02.txt > Date: 31 Jan 2014 11:33:32 GMT+1 >=20 >=20 >=20 > A new version of I-D, draft-johansson-sip-dual-stack-02.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Name: draft-johansson-sip-dual-stack > Revision: 02 > Title: Locating Session Initiation Protocol (SIP) = Servers in a Dual-Stack IP Network > Document date: 2014-01-30 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stack-02.txt > Status: = https://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack/ > Htmlized: = http://tools.ietf.org/html/draft-johansson-sip-dual-stack-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-sip-dual-stack-02 >=20 > Abstract: > RFC 3263 defines how a Session Initiation Protocol (SIP) > implementation, given a SIP Uniform Resource Identifier (URI), = should > locate the next hop SIP server using Domain Name System (DNS) > procedures. As SIP networks increasingly transition from IPv4-only > to dual-stack, a quality user experience must be ensured for dual- > stack SIP implementations. This document supplements the DNS > procedures described in RFC 3263 for dual-stack SIP implementations > and ensures that they properly align to the optimizations detailed = by > Happy Eyeballs. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From richard@shockey.us Fri Jan 31 14:42:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234231A1DBD for ; Fri, 31 Jan 2014 14:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29Idwc8eEAQ for ; Fri, 31 Jan 2014 14:42:04 -0800 (PST) Received: from oproxy16-pub.mail.unifiedlayer.com (oproxy16-pub.mail.unifiedlayer.com [69.89.22.201]) by ietfa.amsl.com (Postfix) with SMTP id F2F061A058D for ; Fri, 31 Jan 2014 14:42:02 -0800 (PST) Received: (qmail 10883 invoked by uid 0); 31 Jan 2014 22:41:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy16.mail.unifiedlayer.com with SMTP; 31 Jan 2014 22:41:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=+Qy7wY5CDh6pYreUXUC+e3B3JFAbQcjj44ltDh97QgA=; b=PHLuxSx/KTstMLTJFulL0nYh9U0arLlNg6WEOhm6/wKkCf6eA8y33Rfskmet01Tsp41tfP3DY1WR6NvTsiTBIRJQ4WjcfMMdxfmMWtRBvHzbxiGYI3C+3L7mtgGhjc7B; Received: from [173.79.179.104] (port=57501 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W9Mmb-000375-6t; Fri, 31 Jan 2014 15:41:57 -0700 From: "Richard Shockey" To: , "'DISPATCH'" , Date: Fri, 31 Jan 2014 17:41:54 -0500 Message-ID: <01a201cf1ed5$a57db4e0$f0791ea0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01CF1EAB.BCA84920" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8e1RWe7HcGrHocRxuLkODRtsT0WA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Subject: [sipcore] If you recall Henning spoke to us at IETF 86 on The end of POTS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 22:42:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A3_01CF1EAB.BCA84920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://www.ietf.org/proceedings/86/slides/slides-86-iab-techplenary-4.pdf Well now you can see it in action. The FCC Order on the PSTN Transition. http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-14-5A1.pdf It's not too bad for an FCC order only 120 pages or so. :) Even ENUM gets a prominent mention. Cheers Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_01A3_01CF1EAB.BCA84920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

http://www.ietf.org/proceedings/86/slides/slides-86-iab-techple= nary-4.pdf

 

Well now you = can see it in action.

 

The FCC = Order on the PSTN Transition.

 

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-1= 4-5A1.pdf

 

It’s not too bad for an FCC order only 120 pages = or so. J

 

Even ENUM = gets a prominent mention. 

 

Cheers =

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http//www.sipforum.org

"Money is the answer, what is the question?" = tm

 

 

------=_NextPart_000_01A3_01CF1EAB.BCA84920--