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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: 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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: 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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-dime-erp-16.txt
Reviewer: Elwyn Davies
Review Date: 20 Jan 2013
IETF LC End Date:
IESG Telechat date: 24 jan 2013
Summary: Not ready assuming I have correctly identified that the
requirements specified in RFC 5295 below are not met by this usage of
the DSRK. Generally the use of the term 'domain' in this draft is
rather cavalier, as it fails to explicitly tie it back to the restricted
meaning of RFC 5295 and does not clarify how nodes find out what domain
name they should be using.
Major issues:
s5, para 1:
Para 1 states:
To
achieve this, it must learn the domain name of the ER server. How
this information is acquired is outside the scope of this
specification, but the authenticator might be configured to advertize
this domain name, especially in the case of re-authentication after a
handover.
It appears that declaring learning the domain name out of scope for this
specification is in conflict with RFC 5295, para 4 (top of page 12):
Usages that make use of the DSRK must define how the peer learns the
domain label to use in a particular derivation.
This matter escaped me on the previous pass, when I just asked whether
there was any suggestions of how the advertisement might be done.
Minor issues:
s3: In my Last call review of this document (version 12) I queried the
use of the phrase 'the existence of at most one (logical) ER server
entity' in two places in s3. I received an answer from one of the the
authors that suggested that the phrase was self-explanatory. At the
time I did not push back on this and no change has been made. On
re-reading the latest version of the draft and the author's reply, I
(still) feel that it would help to explain:
(1) Why having more than one ER server in a domain is a mistake -
apparently because this will result in EAP 'failing inappropriately' in
some cases which would seem to be a reason to specifically deprecate
having more then one, and explaining just what the inappropriate
consequences would be.
(2) The consequences of having zero ER servers in a domain. The reply
to my comments seem to imply that this would just result in the
'protocol failing gracefully'. However, reading RFC 6695, para 2 of
s5.1 seems to imply that having zero ER servers in the local (visited)
domain may not be fatal if there is an ER server in the home domain (see
also s4 of this draft). If I have interpreted this correctly, then
there is a distinction between the cases (home vs arbitrary visited
domain) that could usefully be brought out here rather than leaving the
reader to work it out from later reading.
s3, last sentence of para 1: ''we assume only one ER server that is
*near* the peer involved in ERP": How are we to interpret 'near' here?
Topologically or physically? How would the peer know a server was
'near' it or nearer than some other server?
Nits/editorial comments:
s2/s3: I assume that the term 'domain' is intended to be interpreted as
in RFC 5295, i.e. as a shorthand for Key Management Domain. This needs
to be spelt out here. Similarly 'home domain', 'local domain' and
'visited domain' should be explicitly mentioned as (presumably) having
the same meanings as in RFC 6696.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art