Skip to main content

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.