RE: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07

Linda Dunbar <linda.dunbar@huawei.com> Tue, 27 June 2017 20:22 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74D126B71; Tue, 27 Jun 2017 13:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 kab8yM_smbd0; Tue, 27 Jun 2017 13:22:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE1D1200ED; Tue, 27 Jun 2017 13:22:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY04760; Tue, 27 Jun 2017 20:22:13 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 21:22:11 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Tue, 27 Jun 2017 13:22:05 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Peter Saint-Andre - Filament <peter@filament.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "precis@ietf.org" <precis@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-precis-7613bis@ietf.org" <draft-ietf-precis-7613bis@ietf.org>
Subject: RE: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07
Thread-Topic: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07
Thread-Index: AdLuzwlSicte5jFwS92cRaxDldpIjAAQlv4AAAPukoAAGGnvQA==
Date: Tue, 27 Jun 2017 20:22:05 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593D9AA6@SJCEML702-CHM.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> <3feb4084-d038-9253-fc48-e739d846102f@filament.com> <f070d840-792d-8447-4e2a-f919019adff1@filament.com>
In-Reply-To: <f070d840-792d-8447-4e2a-f919019adff1@filament.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.138]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5952BE75.0116, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: befc2f0ab0b180b3a3ba228e0f21ff5f
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PQDqQk9mDyctReGcmY9TDWlkvjM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2017 20:22:18 -0000

Peter, 

Thank you very much for the explanation and the revised wording. Your new wording is much clearer and help people to understand why to postpone the checking. 

Thank you. 

Linda Dunbar

-----Original Message-----
From: Peter Saint-Andre - Filament [mailto:peter@filament.com] 
Sent: Monday, June 26, 2017 8:41 PM
To: Peter Saint-Andre - Filament <peter@filament.com>; Linda Dunbar <linda.dunbar@huawei.com>; gen-art@ietf.org
Cc: precis@ietf.org; ietf@ietf.org; draft-ietf-precis-7613bis@ietf.org
Subject: Re: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07

On 6/26/17 5:48 PM, Peter Saint-Andre - Filament wrote:
> Hi Linda,
> 
> Thanks for your review. Comments inline.
> 
> On 6/26/17 4:53 PM, Linda Dunbar wrote:
>>  
>> Reviewer: Linda Dunbar
>> Review result: Ready
>>  
>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>> the IESG for the IETF Chair.  Please treat these comments just like 
>> any other last call comments.
>>  
>> For more information, please see the FAQ at
>>  
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>  
>> Document: draft-ietf-precis-7613bis
>> Reviewer: Linda Dunbar
>> Review Date: 2017-06-25
>> IETF LC End Date: 2017-06-27
>> IESG Telechat date: 2017-07-06
>>  
>> Summary:
>> The document is written very clear. Even for a person who is not 
>> familiar with the App area, I can follow through the description. The 
>> document is ready for publication as standard track document Major issues:
>>  
>> One Minor issue:
>>  
>> Page 6 last paragraph has:
>> /SASL mechanisms SHOULD delay any case////mapping to the last 
>> possible moment, such as when doing a lookup////by username, 
>> performing username comparisons, or generating a////cryptographic 
>> salt from a username (if the last possible moment////happens on the 
>> server, then decisions about case mapping can be a////matter of 
>> deployment policy). In keeping with [RFC4422], SASL////mechanisms are 
>> not to apply this or any other profile to////authorization 
>> identifiers, only to authentication identifiers./
>>  
>> What does "last possible moment" mean? When I read it, I thought it 
>> meant wait until you got all the characters. But the next sentence 
>> mentions "..happens on the server". How is the "server" related to 
>> the entity that check the user name & password?
> 
> Many authentication decisions happen on an application server to which 
> a user-oriented client connects (think of an email client connecting 
> to an email server). By "last possible moment" we're referring to 
> processing within the application server or an authentication module 
> thereof - for instance, instead of performing case mapping on first 
> receiving data from the client (thus implying that the case 
> information is lost through most of the processing stages), it's 
> better to lose that information only at the very end. Do you feel it 
> would it help to add a more detailed description of the reasoning here?

Here is a proposed adjustment to the text:

OLD

      SASL mechanisms SHOULD delay any case
      mapping to the last possible moment, such as when doing a lookup
      by username...

NEW

      Because case mapping results in
      information loss, in order to retain that information for as long
      as possible during processing, implementations SHOULD delay any
      case mapping to the last possible moment, such as when doing a
      lookup by username...

Peter