Subject: Re: Gen-art LC review of draft-ietf-dime-erp-12

From: Glen Zorn <[email-masked]>
Date: Wed, 26 Sep 2012 08:03:05 +0700

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
 >
 > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 >
 > 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 
inappropriately.

> 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?

Yes.

> 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.