Re: [Dime] Gen-art LC review of draft-ietf-dime-erp-12

Glen Zorn <> Wed, 26 September 2012 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A42721F8472; Tue, 25 Sep 2012 18:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Ub7qmI-aPwl; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 762AE21F8425; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: by danh15 with SMTP id h15so10769dan.31 for <multiple recipients>; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nvhAs3Pg10fWPAU8MbM+lMbjkE+aYkedy9fhadOGw5o=; b=ILHvijeq3KI53TF8G71Sw7YzY/92UURIkmYWE4/oxwmNVHIm1mPbpMgA+QGa4gs/Kr 64YdAhi3ZmNVA8dnQb5XAjfw+4A9msTRYV49su7Wps6Y/dgGS18u71+iu/9qjNzfL/P9 QHMH/boIEGUUBjxufrlX2VONOzOnu3GPsygOTahXz5O4vYpCE8+cgRuUP4Y8kM9Wrhyy 3PkhQTpo6X1eRasu/eRJuCBys0SV5vCKbIRclwMuBwuojk2phazqmttzMGw7VLBTlxT2 hN1iaYpak31E8d9k68KhY7b/i7euWXG4twneJgZbzAJaDCOJNdoEVl3KBp/L9uzTfwFT zZPQ==
Received: by with SMTP id gj4mr50287085pbc.48.1348621390179; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id gf3sm1104098pbc.74.2012. (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 18:03:09 -0700 (PDT)
Message-ID: <>
Date: Wed, 26 Sep 2012 08:03:05 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0
MIME-Version: 1.0
To: Elwyn Davies <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, draft-ietf-dime-erp <>, General Area Review Team <>, dime mailing list <>,
Subject: Re: [Dime] Gen-art LC review of draft-ietf-dime-erp-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Sep 2012 01:03:11 -0000

On 09/25/2012 05:03 AM, Elwyn Davies wrote:

> Gen-art LC review of  draft-ietf-dime-erp-12 I am the assigned Gen-ART
 > reviewer for this draft. For background on Gen-ART, please see the
 > FAQ at
 > <>.
 > Please resolve these comments along with any other Last Call
 > comments you may receive.
 > Document: draft-ietf-dime-erp-12.txt Reviewer: Elwyn Davies Review
 > Date: 24 September 2012 IETF LC End Date: 24 September 2012 IESG
 > Telechat date: (if known) -
 > Summary: Almost ready for the IESG. There are some minor wording
 > issues to sort out in s3, some advice on advertising domain names in
 > s5 and possibly some extra words needed in the security
 > considerations. In addition there a few minor nits.
 > Major issues: None.
 > Minor issues: s3: Both paragraphs use the phrase '...document assumes
 > the existence of at most one...'. Does this really mean 'exactly
 > one'?

Oddly enough, it means just what it says.

> If not, what happens if there  is exactly zero servers for either
 > type?

Both protocols will fail gracefully.

> What would the consequences of  there being more than one
 > logical server?

If the message is directed to a logical server not in possession of the 
rRK or rDSRK (depending upon where the server is located), ERP will fail 

> Is this tied into the statement  in s4:
 > The ER server is located either in the home domain (same as EAP
 > server) or in the visited domain (same as authenticator, when it
 > differs from the home domain).

I don't think so.

> This would seem to imply that  the zero case means that it may not be
 > essential to have an ER server in a domain.

It's not.

 > S3, para 1:
 >> If multiple ER servers are deployed in the domain, we assume that
 >> they can be used interchangeably.
 > Are we talking physical servers here?


> If not please refer to the
 > previous comment.
 > s5, para 1: How would the authenticator advertise the domain name in
 > this context?

That is outside the scope of this draft.

 > s13: Looking at the various security considerations that are
 > imported, I wondered if some extra words were needed in respect of a
 > couple of the cases: - s8.4 of RFC 4072: (does distributing the
 > bootstrapping master key make things any worse here?) -

I don't think so.

> s8 of RFC
 > 6696 (does the DIME usage preserve the limited key scope?; is the
 > domino effect equally well avoided?)

Yes and yes.

 > Nits/editorial comments:
 > s1: 'and re-use the Diameter EAP commands (DER/DEA).' : DER and DEA
 > ought to be expanded here. Or it might be less verbose to point at s2
 > where they are currently expanded, thus: 'and re-use the Diameter EAP
 > commands listed in Section 2.'

These are both defined in RFC 4072.

 > s2, para 2: Need to expand acronyms rRK and rDSRK.

rRK is defined in RFC 6696.

 > s4, para 7: Should explicitly say that the ERP/DEA message is sent to
 > the authenticator.

It's not: the authenticator is an EAP protocol entity.  The message is 
sent to the Diameter peer, like all Diameter answer messages.

 > s8.3.3: s/RGC 6696/RFC 6696/

Fixed, thanks.