The Network Access Identifier
draft-ietf-radext-nai-15
Yes
(Benoît Claise)
No Objection
(Adrian Farrel)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 10 and is now closed.
Benoît Claise Former IESG member
Yes
Yes
(for -10)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -12)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(2014-12-03 for -12)
Unknown
I support Alissa's concerns on privacy.
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-04 for -14)
Unknown
Thanks for all your efforts on this document.
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-03 for -12)
Unknown
Thanks for addressing my comments in version -12. -- Sections 2.6 and 2.6.1 -- Good work on these sections. This is difficult stuff, and I think you've handled it well -- at least, in the best way you can. My favourite bit it this one, which is absolutely true: The suggestion in the above sentence contradicts the suggestion in the previous section. This is the reality of imperfect protocols. Thanks for making that reality clear.
Brian Haberman Former IESG member
No Objection
No Objection
(2014-12-01 for -11)
Unknown
I have no problem with the publication of this document, but I do have a few points for you to consider. 1. The references contain RFC 5335. However, 5335 has been obsoleted by RFC 6532. 2. Can you drop the "hope" from section 1.3 and make a more definitive statement about the use of this document? Additionally, most of 1.3 does not read like the Purpose of this document. Can it be tightened up by removing some of the nebulous text on AAA and non-AAA systems and focus on the NAI itself?
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2015-01-23)
Unknown
As far as I can see, and based on my attempt to find people who would still have an issue, we have cleared the issues that I worried about earlier. Thanks for the updates and working on this topic!
Joel Jaeggli Former IESG member
No Objection
No Objection
(2014-12-03 for -12)
Unknown
imho I think the hope statements are ok. and I can live with draft 12 ------ opsdir review of 11 (by Mehmet Ersue) for the record. I have reviewed the document "The Network Access Identifier" (draft-ietf-radext-nai-11.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Obsoletes: RFC 4282 Current draft status: Submitted to IESG for Publication Summary: The document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document obsoletes RFC 4282. I would suggest to change: "In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server." as "Concerning the support of roaming capability, one of the requirements is the ability to identify the user's home authentication server." It is praiseworthy that the draft includes a section on the administration of names, which however has been kept short and handles NAI realm namespace piggybacks, NAI realm name uniqueness and the location of the authentication server. I agree with Brian Haberman who asks to drop the "hope" from section 1.3 making a more definitive statement about the use of the document. There are three occurrences of the verb hope, which should be rewritten in a more explicit manner. I don't see any other issues from the operations and management pov. There are some nits in the draft: The format of Table of Contents is wrong. It lists Appendix A before Introduction. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs -- Obsolete informational reference: RFC 5335 (Obsoleted by RFC 6532)
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-04 for -12)
Unknown
Thank you for including an explanation of what is intended by inter-domain authentication per my previous discuss point. I think this will be helpful to the reader. I also appreciate the language updates to get rid of the term identity and replace it with identifier as well as you using the suggestions I provided for the NAI definition. The changes do help, thank you. I support Barry's discuss on privacy concerns and appreciate the text you provided to address this concern.
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-04 for -14)
Unknown
Thanks for addressing all of my comments.
Richard Barnes Former IESG member
No Objection
No Objection
(for -12)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -12)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-12-03 for -11)
Unknown
- This is not a blocking DISCUSS as it may be a feature request but I'd really like to chat about it. In 2.4 you say that the username can be omitted or be anonymous and that other protocols can support that which is fine. But shouldn't you also consider that sometimes (parts of) the realm part might also be sensitive and handled similarly? E.g. if the "real" NAI was "joebloggs@sensitive.example.org" then (assuming example.org is sufficient for routing) wouldn't it be nice if "@example.org" or "@anonymous.example.org" could be sent as the visible NAI with the full NAI being protected elsewhere in the protocol? For example replacing the string sensitive in that NAI with the name of a disease or counselling service might be a real use case. Did the WG discuss this possibility? (Note: I'm not trying to insist that this be done, I'd just like to chat about it since it could be easy enough to allow for here even recognising that it might not be possible in some important use-cases if the "protected" other protocol field is only expected to contain the username part of the NAI.) - I agree with Barry's discuss and Aliss's concerns and would like to see the follow up discussion on that and suspect that involving the WG in that discussion would be good. Even if the document is perhaps not "pushing" the idea of using the same identifier everywhere, I do think that an analysis of the impacts of doing so, and of how to usefully not do so, should be done, whether or not all of that analysis output is needed in this document. That is, I could buy the concept that the WG might take on the task of analysing the consequences of (not)reuse of NAIs in multiple contexts in a separate document, if the WG would really do that in a timely manner. And if the WG waned to do that, then some simple qualifiers added here and there might be sufficient to handle Barry and Alissa's points. - Generally, I'd prefer if the term "identifier" was used throughout, and the term "identity" was never used, or only very carefully. The abstract does not do that IMO. Other text seems pretty good though but I didn't check fully. - Intro: " We suggest that this re-use is good practice." needs a qualifier to handle the privacy issues. (Recommending the format is fine, which goes to Alissa's discuss.) - 1.3: Same point: "as there is no need to maintain multiple identifiers for one user" needs a qualifier. - 1.3, 2nd last sentence: do you mean sybil attacks here or something else? If the former saying so would be good (or adding a ref), if the latter can you tell me what you mean? - 2.4, last para: saying "is typically required" seems a bit weak, I wonder why you cannot require that the realm part be routable or some such?
Ted Lemon Former IESG member
No Objection
No Objection
(2014-12-04 for -12)
Unknown
I support the changes Alissa has proposed to address the privacy concerns she raised.