Mobile IPv4 RADIUS Requirements
draft-ietf-mip4-radius-requirements-04

[Ballot comment]
Some "Minor nits" from Pasi Eronen's SecDir review:

1) Section 6, "When it comes to protecting attributes in Access
Request, RFC 2868 section 3.5 provides a mechanism for encrypting
RADIUS attributes": This should probably refer to Access-Accept
messages, not Access-Requests.

2) The document contains many references to various RFCs that are not
listed in the References section. To give just one example: "Existing
RADIUS authentication procedures, e.g.  Message-Authenticator (80)
described in RFC2869, are used."

3) Section 3.1, "It is required of the RADIUS servers to be able to
understand and process the attributes described in this specification"
...except that no attributes are described in this specification.

4) From idnits (if these references are useful, they should be
mentioned somewhere in the text as well).

== Unused Reference: 'I-D.nakhjiri-radius-mip4' is defined on line
231, but no explicit reference was found in the text
== Unused Reference: 'RFC2868' is defined on line 236, but no explicit
reference was found in the text
== Unused Reference: 'RFC3579' is defined on line 239, but no explicit
reference was found in the text

[Ballot discuss]
[From Pasi Eronen's SecDir review:]

1) Scope: We already have one RFCs that describes the AAA requirements
for Mobile IP (RFC 2977); and RFC 3957 also contains its requirements
from the AAA infrastructure.  This document should better describe its
relationships to these two: why do we need a yet another requirements
document?

Perhaps the requirements in earlier documents were wrong or
unnecessary? (As is suggested later: "Extending RADIUS in a way that
fulfills the full list of requirements in [RFC2977] will not be
attempted") If so, at least some text about what's wrong would be
helpful.

2) The security considerations section states that "For instance,
the concern of using AAA protocols that use hop-by-hop security
(Diameter/RADIUS) to distribute keys is nothing new."

This certainly isn't a new topic, but that doesn't mean it's simple.
RFC 4004 had to consider this is in some detail, and provide
alternative that doesn't reveal the keys to proxies (redirect).
And you probably can't avoid considering draft-housley-aaa-key-mgmt.
Perhaps we should include pointers to these documents?

3) Section 3.1, "RADIUS proxies are expected to be able to process
these attribute." This needs more explanation: what processing is
expected from proxies, and why? (Presumably hop-by-hop attribute
level security mechanisms need support from proxies, but is
there something else?)

[Note]: 'Tim, we need your Discuss based on Pasi''s review on this document.
Document Shepherd is Pete McCann <pete.mccann@motorola.com>
' added by Jari Arkko

[Ballot comment]
From the Gen-ART Review by Vijay K. Gurbani...

  1) Section 1: s/[RFC3957] all based/[RFC3957], all based
  (The comma improves readibility)

  2) Section 3: s/reqiuired/required

  3) Section 3.1: In the first and third bullet item, it appears
  appropriate that the word "required" be upper-cased to denote its
  use as a normative declaration.  More so since bullet item two
  contains the word "MUST" in normative fashion.  I believe that
  the authors are making a normative set of declarations for the
  goals, so it appears uneven to have a MUST in the second bullet
  item and not a pair of REQUIREDs in the other two bullets.

[Ballot discuss]
The normative reference [zorn-radius-keywrap] is in status Dead. It was not approved by the IESG because it was updating standards track documents which is not an appropriate for an Informational RFC. The IESG recommended for the document to be submitted to the RADEXT WG, or as an AD sponsored individual submission for standards track. The RADEXT chairs and the editor agreed to consider draft-zorn as an input for the crypto-agility work on the RADEXT charter.

[Ballot comment]
>    o  All RADIUS work MUST be backward compatible with existing RADIUS
>      RFCs, including RFCs 2865-2869, 3162, 3575, 3576, 3579, 3580 and
>      4668-4671.

  Should cite all the RFCs for which compatibility is being required.

[Ballot discuss]
Holding a Discuss for Last Call comments, given that Last Call period ends a few days after the IESG telechat. If there are substantial comment I will alert the IESG.

Results of the AD review:

I have made my AD review on this, and sent the
draft forward to IETF Last Call. The document
looks good. I did see one typo and marked it in
the tracker so that the RFC Editor will take
care of it.

I also have an ongoing discussion with
the RADEXT chairs and the authors about the
normative dependency to draft-zorn; I worry
a little bit about dependencies to drafts without
WG status, and also it was unclear to me whether
the reference actually has to be normative,
particularly in a requirements draft. When that
discussion completes we can make the necessary
change if needed, along with any other changes
resulting from the IETF Last Call and IESG review.

PROTO Write-up

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Pete McCann is the document shepherd. Yes, I have personally reviewed
the document and it is ready for publication.

> (1.b) Has the document had adequate review both from key WG
members
> and from key non-WG members? Does the Document Shepherd
have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The document has been adequately reviewed both by the mip4 working group
and members of the radext working group. I have no concern about the
reviews.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar
with
> AAA, internationalization or XML?

No concerns.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document,
or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has
indicated
> that it still wishes to advance the document, detail those
> concerns here.

No issues.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand
and
> agree with it?

There is unanimous consensus to advance the document. I believe that
the
WG as a whole understands the requirements and is comfortable with the
document.

> (1.f) Has anyone threatened an appeal or otherwise indicated
extreme
> discontent? If so, please summarise the areas of conflict
in
> separate email messages to the Responsible Area Director.
(It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No appeals have been threatened.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/). Boilerplate checks
are
> not enough; this check needs to be thorough. Has the
document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

Only nits found are 3 unused references in the Informative References
section. These documents may provide useful context for the work
even though they aren't referenced in the text. I would be ok with
removing them if the RFC Editor wishes.

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents
that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative
references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

The document has split its references into Normative and Informative.
The intended status of the document is Informational so there are no
downward references. However, there is one Normative reference
[zorn-radius-keywrap] which is still only an internet-draft.

None of the Informative references are actually used in the text.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggested a
> reasonable name for the new registry? See
> [I-D.narten-iana-considerations-rfc2434bis]. If the
document
> describes an Expert Review process has Shepherd conferred
with
> the Responsible Area Director so that the IESG can appoint
the
> needed Expert during the IESG Evaluation?

The document contains no parameter assignments. The IANA considerations
section notes this.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly
in
> an automated checker?

No such formal notation is used.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Writeup? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

This document defines a set of goals and a set of non-goals for
RADIUS extensions to handle Mobile IPv4 key distribution. Among
the goals are the definition of new attributes, backwards compatibility,
and turning FAs and HAs into RADIUS clients. Among the non-goals
are any RADIUS extensions to support security, transport reliability,
or the size of the available message set. Together, the goals and
non-goals serve to define and limit the scope of the Mobile IPv4
RADIUS work that will take place when this document is approved.

> Working Group Summary

The document completed last call in the mip4 working group in May, 2007.
It was also reviewed by selected members of the RADEXT working group.

> Personnel
> Who is the Document Shepherd for this document? Who is
the
> Responsible Area Director?

Pete McCann is the document shepherd. Jari Arkko is the responsible AD.

-Pete