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

From: Elwyn Davies <[email-masked]>
Date: Mon, 24 Sep 2012 23:03:23 +0100

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'?  If not, what 
happens if there is exactly zero servers for either type?  What would 
the consequences of there being more than one logical server?  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).
This would seem to imply that the zero case means that it may not be 
essential to have an ER server in a domain.

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?

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?)
- s8 of RFC 6696 (does the DIME usage preserve the limited key scope?; 
is the domino effect equally well avoided?)

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

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

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

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

---

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

I don't think so.

 > essential to have an ER server in a domain.

It's not.

 > Are we talking physical servers here?

Yes.

> If not please refer to the
 > previous comment.
 >

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.

 > 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

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.