Re: [secdir] SECDIR review of draft-shin-augmented-pake-10

"SeongHan Shin" <seonghan.shin@aist.go.jp> Fri, 17 February 2012 03:40 UTC

Return-Path: <seonghan.shin@aist.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FBD21E806E for <secdir@ietfa.amsl.com>; Thu, 16 Feb 2012 19:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+0vllQRysNM for <secdir@ietfa.amsl.com>; Thu, 16 Feb 2012 19:40:40 -0800 (PST)
Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD5121E8056 for <secdir@ietf.org>; Thu, 16 Feb 2012 19:40:39 -0800 (PST)
Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id q1H3eHZm016064; Fri, 17 Feb 2012 12:40:17 +0900 (JST) env-from (seonghan.shin@aist.go.jp)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1329450018; bh=xboESLrppbYSO+7tourBG069SNAgg4FeSCp+e8aGgzI=; h=From:Date:Message-ID; b=k0a+T9EGNWIvYFAmOhYXS618ZTu2SucI9yxH1ZZFlUgdLUHYIjGIl94jnoA6fDXhP fFG+iBTxlBe0PaPX5eouzeuwfr5iO+en9tzBG0yQLSUcjBrHISM4v5xnkKvgRy5sdD 5OhkfbbjxxiTvWqshYiKdsz+B+95KePvuv05nzIc=
Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id q1H3eGd2008601; Fri, 17 Feb 2012 12:40:16 +0900 (JST) env-from (seonghan.shin@aist.go.jp)
Received: by smtp4.aist.go.jp with ESMTP id q1H3eBjd014425; Fri, 17 Feb 2012 12:40:11 +0900 (JST) env-from (seonghan.shin@aist.go.jp)
From: "SeongHan Shin" <seonghan.shin@aist.go.jp>
To: "'Tero Kivinen'" <kivinen@iki.fi>, "'Tina TSOU'" <Tina.Tsou.Zouting@huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A80C27D872@szxeml526-mbs.china.huawei.com> <4F20D424.1060901@gmail.com> <C0E0A32284495243BDE0AC8A066631A80C2830D4@szxeml526-mbs.china.huawei.com> <20258.43953.678320.842027@fireball.kivinen.iki.fi>
In-Reply-To: <20258.43953.678320.842027@fireball.kivinen.iki.fi>
Date: Fri, 17 Feb 2012 12:40:16 +0900
Message-ID: <007f01cced25$dcf442b0$96dcc810$@aist.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-language: ja
Thread-index: AQF3vzRYahQsHTw/d2zaNYM5Ipa7XALQ31jOAk7mURgCGsBz7Jaw4WLA
X-Mailman-Approved-At: Fri, 17 Feb 2012 01:52:32 -0800
Cc: 'Kaz Kobara' <k-kobara@aist.go.jp>, seonghan.shin@aist.go.jp, draft-shin-augmented-pake@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-shin-augmented-pake-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2012 03:40:44 -0000

Dear Tina and Tero,

Thank you very much for your comments!
The following changes are reflected to a next version of our I-D.


> I found some editorial glitches and the use of "temporal" when "temporary"
> was intended, but someone else can catch those.
Corrected to "temporary"


> Reference K11 is now RFC 6467. That means the Notify message type and the
> GSPM payload type have now been assigned (16424 and 49 respectively) and
> can be inserted into the document where it currently says "TBD".
I updated reference K11 to RFC6467 and inserted the assigned values into the
document.


> The request to IANA names the wrong registry. The correct name is "IKEv2
> Secure Password Methods" registry, established by RFC 6467.
Corrected.


> > The relationship between this document and RFC 6467 is odd. In the
> > ordinary course of events this document would have a normative
> > dependency on RFC 6467.
> 
> Not exactly. The original intention is that all documents using numbers
> defined in my draft (now RFC6467) would be self-containing, and there
might
> not even be need for publishing my draft as RFC, it was originally just
> written as tool so that all secure password method drafts could coordinate
> their numbers. As it is now published as RFC, I think it is ok to make
either
> normative or non-normative reference to it, depending whether the document
> itself is self-containing or not.
> 
> Currently I think all the secure password method documents are
> self-containing, thus non-normative reference is needed, the implementor
> who is implementing the secure password method in question, does not NEED
> to read RFC6467 to be able to implement for example
> draft-shin-augmented-pake as that draft already contains all information
> needed.
> 
> > It is obvious that the latter was written after the present document,
> > and avoidance of the dependency was deliberate on both sides. Still,
> > the authors of this document might reconsider, even though RFC 6467
> > would be a down-reference since it is Informational.
> 
> The intended status of draft-shin-augmented-pake is listed as
experimental,
> so there really a down-reference problem there?
> 
> Anyways as draft-shin-augmented-pake self-contained, the reference can be
> non-normative.
Thanks, Tero!
I just keep reference RFC6467 in non-normative.


Best regards,
Shin


------------------------------------------------------------------
SeongHan Shin
Research Center for Information Security (RCIS),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------


> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: Friday, January 27, 2012 10:51 PM
> To: Tina TSOU
> Cc: secdir@ietf.org; draft-shin-augmented-pake@tools.ietf.org
> Subject: [secdir] SECDIR review of draft-shin-augmented-pake-10
> 
> Tina TSOU writes:
> > The relationship between this document and RFC 6467 is odd. In the
> > ordinary course of events this document would have a normative
> > dependency on RFC 6467.
> 
> Not exactly. The original intention is that all documents using numbers
> defined in my draft (now RFC6467) would be self-containing, and there
might
> not even be need for publishing my draft as RFC, it was originally just
> written as tool so that all secure password method drafts could coordinate
> their numbers. As it is now published as RFC, I think it is ok to make
either
> normative or non-normative reference to it, depending whether the document
> itself is self-containing or not.
> 
> Currently I think all the secure password method documents are
> self-containing, thus non-normative reference is needed, the implementor
> who is implementing the secure password method in question, does not NEED
> to read RFC6467 to be able to implement for example
> draft-shin-augmented-pake as that draft already contains all information
> needed.
> 
> > It is obvious that the latter was written after the present document,
> > and avoidance of the dependency was deliberate on both sides. Still,
> > the authors of this document might reconsider, even though RFC 6467
> > would be a down-reference since it is Informational.
> 
> The intended status of draft-shin-augmented-pake is listed as
experimental,
> so there really a down-reference problem there?
> 
> Anyways as draft-shin-augmented-pake self-contained, the reference can be
> non-normative.
> --
> kivinen@iki.fi