Re: [tram] draft-ietf-tram-stunbis
Noriyuki Torii <torii0573@gmail.com> Mon, 12 March 2018 03:00 UTC
Return-Path: <torii0573@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212DB1243F6; Sun, 11 Mar 2018 20:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.643
X-Spam-Level:
X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 AbkswN-TneVw; Sun, 11 Mar 2018 20:00:34 -0700 (PDT)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2C41200A0; Sun, 11 Mar 2018 20:00:34 -0700 (PDT)
Received: by mail-ot0-x229.google.com with SMTP id f11so13869756otj.12; Sun, 11 Mar 2018 20:00:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gnXBHwpS5YyFFMWWdup8zcHuMbaEE1CH3ggiyvhqDco=; b=mHDW6Gx7quIjInG0e8txnP9Gcptt2Rdv/C8jWUuvI1nboGb2whBHJJ98A8lZqJAVFy fTc7/78pFlMPTmIlBv3kjJ/Onn5nFYEUAJo/u3dVPTRYVKy/vBxzcH5t0a2exWwuaPpb +q3cQMdo4GM1WgWhlhrQBVz52hoVpV3F3OxBPBOSqCPCx1nF5fgDV5OOP/rJE3KGqd09 LrCkY6+PiTyizEb3VLyB9KQtSHJlrEYNDv5rEAQ9dOLIwNi9ISXpeYXcJvP24VFG0oOJ c5zYDTc0jE2ftNb2tiFSnZQYDvrD/NrOLf+syS63oSorEwBBFamDW9t4f/fuE1ZJ3ZCx 5Gjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gnXBHwpS5YyFFMWWdup8zcHuMbaEE1CH3ggiyvhqDco=; b=qL4jx8sgoWoet4npf+zB8Y8uU1i9+vjYdVBO3MPxjpOaBgitpqHumEgHE9f9ZDoJTv E7bC0NeM226LpdPuhEiuBZx1EkgcLZ88So5NTKkVse+bx7/7rWlSDTyK6ScKSn6L0CB0 C5OQvrmhym0+KklroqxUWh3Yb4LX1GKD4JvcPXykGtSi324ite/imwasjV82gDBepLod d3/nHK59Oa/YWA1pQpGLuwN+Q173e6UQNIsQvG8vG9HzxhYAlU5YRraNjP1l8XHeFUN5 60We9BKuG+GNEvMlUi+3RsLN5UWu0qbPpQ3rmEtmJH2awaUeGLta/Czaq2g/0xn2EHHa qUcA==
X-Gm-Message-State: AElRT7G9mfuMT5TiKvoF4d1GODBba+dvmrH/d+yRMDoWQqWXeYkpJ/78 2rdD6CYHxLX4yOp/PL9hAMIGdP8HRIm4lx0MasyahSy0
X-Google-Smtp-Source: AG47ELtAvU4wOxoW8AnjxrCJMP9Y1vt3kpY/z7SqtrDcYBVe43Qw08U+NYt+21CdoNOkG05Ha2Y4zay8+CI/hXdesUs=
X-Received: by 10.157.83.201 with SMTP id i9mr4224246oth.401.1520823633489; Sun, 11 Mar 2018 20:00:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.67.77 with HTTP; Sun, 11 Mar 2018 20:00:33 -0700 (PDT)
In-Reply-To: <9b5529b3-5d0d-e6a6-9481-a947a890acc3@petit-huguenin.org>
References: <CABEjbRJjU2LVb0iDkBavpSxtw-+PowvsyDdg9hhvwX+Gi9Awzw@mail.gmail.com> <9b5529b3-5d0d-e6a6-9481-a947a890acc3@petit-huguenin.org>
From: Noriyuki Torii <torii0573@gmail.com>
Date: Mon, 12 Mar 2018 12:00:33 +0900
Message-ID: <CABEjbRKec0Ro51sedo_MU41YLyhm68xbkBm65DaVG9BiBn+5Yw@mail.gmail.com>
To: draft-ietf-tram-stunbis@ietf.org
Cc: tram@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/x1CSljQKmWIdhtnm_sBJNKrBNbo>
Subject: Re: [tram] draft-ietf-tram-stunbis
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2018 03:00:36 -0000
Hi, Marc Thank you for your consideration and response. > I gave you an answer to that last time, but you did not responded to it. Again, here's the email that justify these values: > > https://www.ietf.org/mail-archive/web/behave/current/msg02535.html > > Please give arguments why that answer is wrong. Unfortunately I haven't received your previous "answer" email at this point yet. (maybe delivery problem?) Therefore I'm sorry to say but the following comment is not taken into account your "answer". Anyway, the email you cited says > UTF-8 encoded sequence of less than 128 characters is up to > (128-1)*6+1=763 bytes, counting the terminating nul here +1 is intended as a extra room for the terminating nul. But such a nul is just a implementation requirement for some programming languages. As far as my understandings, both UTF-8 and PRECIS OpaqueString specification don't require that the nul termination of the string. (If my understanding is wrong, please can anyone correct abobe) Each STUN attributes have its own length field therefore the implementation can detect the end of the string without the terminating nul. So IMHO, such a consideration on an extra room for the terminating nul is not necessarily needed as the STUN specification. This is why the comment I submitted prevously. --- Additionally, I found one more point in section 9.2.4. > * If the request contains neither PASSWORD-ALGORITHMS nor > PASSWORD- ALGORITHM, then the request is processed as though > PASSWORD- ALGORITHM were MD5 (Note that if the original > PASSWORD-ALGORITHMS attribute did not contain MD5, this will > result in a 400 Bad Request in a later step below). > > * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- > ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches > the value sent in the response that sent this NONCE, and (3) > PASSWORD-ALGORITHM matches one of the entries in PASSWORD- > ALGORITHMS, the server MUST generate an error response with an > error code of 400 (Bad Request). The first '*' paragraph says > (Note that if the original > PASSWORD-ALGORITHMS attribute did not contain MD5, this will > result in a 400 Bad Request in a later step below). > But the second '*' paragraph starts with "Otherwise". So if really "the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM", then the second '*' check will be skipped as a whole and the 400 Bad Request will be never generated, whether or not "the original PASSWORD-ALGORITHMS attribute did not contain MD5". I guess it would be preferable something like below. * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, then the request is processed as though PASSWORD-ALGORITHMS was identical to the value sent in the response that was sent this NONCE and PASSWORD-ALGORITHM was MD5. Otherwise, unless PASSWORD-ALGORITHM and PASSWORD-ALGORITHMS are both present, the server MUST generate an error response with an error code of 400 (Bad Request). (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). * Unless (1) PASSWORD-ALGORITHMS matches the value sent in the response that sent this NONCE, and (2)PASSWORD-ALGORITHM matches one of the entries in PASSWORD-ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request). Best regards, Noriyuki Torii 2018-03-11 22:26 GMT+09:00 Marc Petit-Huguenin <marc@petit-huguenin.org>: > Hi, > > Thanks for the review, please see inline. > > Note that the draft submission tool will reopen on 2018-03-18, so no new version of this draft will be published before that. > > On 03/07/2018 04:10 AM, Noriyuki Torii wrote: >> To whom it may concern. >> >> I'm Noriyuki Torii. I have red the updated I-D of STUNbis-16 and found >> some issues would like to be shared. >> >> Hope this may help for improvement. >> >> - Section 9.1.1 and 9.2.2 defines the HMAC key calculation based on some >> elements such that the password, username and realm. >> Sections say those elements should be proccessed using OpaqueString >> profile >> defined in RFC8265. >> >> On the other hand, RFC8265 says in its "Changes from RFC 7613" that >> "Removed UTF-8 as a mandatory encoding, because that is a matter >> for the application." >> >> So, the specification of applied encoding for those elements on >> calculating >> HMAC key is up to STUNbis document. >> >> Please note that username and realm have the applied encoding >> specification >> as UTF-8 in its corresponding STUN attribute description. >> (please see section 14.3 and 14.9) >> But the password doesn't have such a description, therefore some care need >> to be taken. > > Section 9.1.1 and 9.2.2 now have the following text: > > For short-term credentials the HMAC key is defined as follow: > > key = OpaqueString(password) > > where the OpaqueString profile is defined in [RFC8265]. The encoding > used is UTF-8 [RFC3629]. > > [...] > > For long-term credentials that do not use a different algorithm, as > specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: > > key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password)) > > Where MD5 is defined in [RFC1321] and the OpaqueString profile is > defined in [RFC8265]. The encoding used is UTF-8 [RFC3629]. > >> >> - Section 14.6 mentions to the HMAC truncation, but as far as I read, I >> couldn't precisely find out the minimum byte of length of the HMAC. >> >> From my understandings, minimum length >> maybe 16 because >> > The HMAC MUST NOT be truncated below a minimum size of 16 bytes. >> >> OR >> maybe 8 because >> > The value (snip) MUST be a positive multiple of 4 bytes >> AND >> > STUN Usages may specify a minimum length longer than 4 bytes. >> >> Here above I conceived "longer than (but not equal to) 4 bytes". >> IMHO, some clarification will be preferable. > > I removed the last sentence of the paragraph, which did not make sense. > >> >> - There are some occurence such like >> > a UTF-8 [RFC3629] encoded >> > sequence of less than 128 characters (which can be as long as 509 >> > bytes when encoding them or 763 bytes when decoding them). >> >> The sentence inside parenthesis have off-by-one error. >> To be exact, >> >> (which can be less than 509 bytes when encoding them or 763 bytes >> when decoding them) >> >> or alternatively >> >> (which can be as long as 508 bytes when encoding them or 762 bytes >> when decoding them) > > I gave you an answer to that last time, but you did not responded to it. Again, here's the email that justify these values: > > https://www.ietf.org/mail-archive/web/behave/current/msg02535.html > > Please give arguments why that answer is wrong. > >> >> - In Section 9.2.4, there are some typoes. >> Unnecessary extra white space such that "PASSWORD- ALGORITHM". > > Fixed. > >> >> - At page 40, bizzare (perhaps unintended) page break occurs. > > Fixed. > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >
- Re: [tram] draft-ietf-tram-stunbis Marc Petit-Huguenin
- Re: [tram] draft-ietf-tram-stunbis Noriyuki Torii