Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
draft-ietf-radext-rfc3576bis-13

[Ballot discuss]
The RFC 2401 IPsec model does not actually support the concept of a
security policy entry that is "accept protected traffic but don't
require it."  Some of the suggested policies in the security
considerations section seem to rely on this.  Since we have no
mechanism for an application to find out if traffic is protected, I
don't think that you can actually have a secure setup if you sometimes
use IPsec with a given source and sometimes do not.  Please make the
sample policies consistent with RFC 2401.  Also, please take a look at
draft-bellovin-use-ipsec and include the information specified by that
draft.  You don't seem to say what IKE authentication modes need to be
supported. You may get a long way by referring to RFC 4945.

I'm confused by section 6.2.  Does the attack described there actually
happen if the first-hop proxy uses a different secret for each DAS/NAS
and confirms that the right secret is used?  I.E. confirms that the
NAS identity matches the expected NAS identity for the secret?

[Ballot discuss]
This is a discuss discuss in two parts.  To be clear, it is not blocking;  I will clear immediately
after the document comes up on the agenda.

(1) Paul Hoffman has suggested that standards track would be more appropriate than
informational for this specification.  I understand this would necessitate an issue-specific
IETF Last Call, but I tend to agree with Paul.  Is there another reason that I am missing
to stay at informational?

(2) The security considerations section on Impersonation (section 6.2) seem to apply to
implementations of RFC 2865, rather than this specification:

  To address these vulnerabilities RADIUS proxies one hop from the NAS
  SHOULD check whether NAS identification attributes (see Section 3)
  match the packet source address.  Where one or more attributes do not

As far as I can tell, the RADIUS proxy that SHOULD perform this check may be entirely
unaware of this specification.  Is that correct?  If so, publishing the security considerations
here seems unlikely to have much impact.  (I checked RFC 2685, and these considerations
do not seem to be present.)

This is a carryover from RFC 3567, so there is no value in blocking the progression
of this specification.  (Besides, the following paragraph notes that this check cannot always
be performed.)  I would like to hear other ADs thoughts on handling this sort of situation
in the future, though.

[Ballot comment]
The figures in sections 2.1 and 2.2 use Disconnect-Response and CoA-Response as shorthand
for "Disconnect-ACK or Disconnect-NAK" and "CoA-ACK or CoA-NAK" respectively.  These
terms are never defined, and in fact are never used again.  I can't claim it was too hard to figure
out, but it might be better if the meaning was explicitly stated.

Perhaps the terms could be introduced in the text following the figures and implicitly defined
in a parenthetical, in the same way that "Response packet" was introduced in section 2.3:

          The  Authenticator field in a Response Packet (e.g. Disconnect-ACK,
            Disconnect-NAK, CoA-ACK, or CoA-NAK).

[Ballot comment]
The figures in sections 2.1 and 2.2 use Disconnect-Response and CoA-Response as shorthand
for "Disconnect-ACK or Disconnect-NAK" and "CoA-ACK or CoA-NAK" respectively.  These terms are never defined, and in fact are never used again.  I can't claim it was too hard to figure out,
but it might be better if the meaning was explicitly stated.

Perhaps the terms could be introduced in the text following the figures and implicitly defined
in a parenthetical, in the same way that "Response packet" was introduced in section 2.3:

          The  Authenticator field in a Response Packet (e.g. Disconnect-ACK,
            Disconnect-NAK, CoA-ACK, or CoA-NAK).

[Ballot discuss]
This is a discuss discuss in two parts.  To be clear, it is not blocking;  I will clear immediately
after the document comes up on the agenda.

(1) Paul Hoffman has suggested that standards track would be more appropriate than
informational for this specification.  I understand this would necessitate an issue-specific
IETF Last Call, but I tend to agree with Paul.  Is there another reason that I am missing
to stay at informational?

(2) The security considerations section on Impersonation (section 6.2) seem to apply to
implementations of RFC 2865, rather than this specification:

  To address these vulnerabilities RADIUS proxies one hop from the NAS
  SHOULD check whether NAS identification attributes (see Section 3)
  match the packet source address.  Where one or more attributes do not

As far as I can tell, the RADIUS proxy that SHOULD perform this check may be entirely
unaware of this specification.  Is that correct?  If so, publishing the security considerations
here seems unlikely to have much impact.  (I checked RFC 2685, and these considerations
do not seem to be present.)

This is a carryover from RFC 3567, so there is no value in blocking the progression
of this specification.  (Besides, the following paragraph notes that this scheck cannot always
be performed.)  I would like to hear other ADs thoughts on handling this sort of situation
in the future, though.

[Ballot discuss]
This is a discuss discuss.  I will clear immediately after the document comes up on the agenda.

Paul Hoffman has suggested that standards track would be more appropriate than informational
for this specification.

[Ballot comment]
From Gen-ART Review by Ben Campbell.

  In Section 3.2, It would be helpful to mention how Authorize Only
  is used to ease mapping to Diameter, and reference the Diameter 
  Considerations section.  As it is, the reader wonders what the
  semantic effect of the resulting Access-Request message is 
  supposed to be.

  Section 6.2, 4th paragraph, raises a question.  Can a proxy be
  expected to easily know if it is one-hop away from the NAS?  Is the
  mechanism for determining this well-known or documented somewhere
  that could be referenced here?

[Ballot discuss]
Includes comments from the Gen-ART Review by Ben Campbell.

  Section 3, first paragraph, says:
  >
  > All NAS and session identification attributes included in a
  > CoA-Request or Disconnect-Request packet MUST match at least one
  > session in order for a Request to be successful; otherwise a
  > Disconnect-NAK or CoA-NAK MUST be sent.
  >
  What does it mean for a NAS identification attribute to match a
  session? I assume we are using the NAS identifiers as a scope in
  which the session identifiers have meaning, so that all sessions
  could be considered of having an implied NAS property?  This is
  ambiguous.  Please clarify.

  Section 3.1, last paragraph, says:
  >
  > Since Disconnect and CoA responses are authenticated on the
  > entire packet contents, the stripping of the Proxy-State
  > Attribute invalidates the integrity check - so the proxy needs
  > to recompute it.
  >
  Please say the proxy MUST recompute...

  Section 3.5, 5th paragraph, says:
  >
  > When the HMAC-MD5 message integrity check is calculated the
  > Request Authenticator field and Message-Authenticator Attribute
  > should be considered to be sixteen octets of zero.
  >
  Both of these are set to 16 zero octets.  That is not clear.
  Also, please reword to use MUST.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "RADIUS TYPES" registry located at

http://www.iana.org/assignments/radius-types
sub-registry "Values for RADIUS Attribute 101, Error-Cause Attribute [RFC3576]:"

# Value
--- -----
tbd(407) Invalid Attribute Value [RFC-radext-rfc3576bis-09]
tbd(508) Multiple Session Selection Unsupported [RFC-radext-rfc3576bis-09]

We understand the above to be the only IANA Action for this
document.

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?



The Document Shepherd is David Nelson. I have personally reviewed the

document.



(1.b) Has the document had adequate review from both key WG members

And key non-WG members? Does the Document Shepherd have any concerns

about the depth or breadth of the reviews that have been performed?



Yes. This document has been through two RADEXT WG last calls.



(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?



This document is a revision of RFC 3576, so there is existing

operational experience.



(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. Has an IPR disclosure related to this

document been filed? If so, please include a reference to the disclosure

and summarize the WG discussion and conclusion on this issue.



No concerns.



(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 consensus behind this document. At various points,

6 people have posted review comments or made contributions relating

to the document.



The issues raised and the resolutions are available for inspection at

http://www.drizzle.com/~aboba/RADEXT/



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



(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?



Yes. An output of the run on this revision of the ID by the online

nits checker:



idnits 2.04.09



tmp/draft-ietf-radext-rfc3576bis-08.txt:



Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:



----------------------------------------------------------------------------



No issues found here.



Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:



----------------------------------------------------------------------------



No issues found here.



Checking nits according to http://www.ietf.org/ID-Checklist.html:



----------------------------------------------------------------------------



No issues found here.



Miscellaneous warnings:



----------------------------------------------------------------------------



No issues found here.



Checking references for intended status: Informational



----------------------------------------------------------------------------



== Missing Reference: 'Note 1' is mentioned on line 956, but not

defined

'[Note 1] Where NAS or session identification attributes are

inclu...'



== Missing Reference: 'Note 3' is mentioned on line 970, but not

defined

'[Note 3] When included within a CoA-Request, these attributes...'



== Missing Reference: 'Notes 1' is mentioned on line 908, but not

defined

'0+ 0 0 97 Framed-IPv6-Prefix [Notes 1,6]...'



-- Looks like a reference, but probably isn't: '6' on line 908

'0+ 0 0 97 Framed-IPv6-Prefix [Notes 1,6]...'



== Missing Reference: 'Note 2' is mentioned on line 962, but not

defined

'[Note 2] The Reply-Message Attribute is used to present a

display...'



== Missing Reference: 'Note 7' is mentioned on line 998, but not

defined

'[Note 7] Within CoA-Request packets, Vendor-Specific Attributes...'



== Missing Reference: 'Note 5' is mentioned on line 982, but not

defined

'[Note 5] When included within a CoA-Request, these attributes...'



== Missing Reference: 'Note 4' is mentioned on line 976, but not

defined

'[Note 4] When included within a successful Disconnect-Request

(wh...'



== Missing Reference: 'Note 6' is mentioned on line 987, but not

defined

'[Note 6] Since the Framed-IP-Address, Framed-IPv6-Prefix and

Fram...'



** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306)





Summary: 1 error (**), 8 warnings (==), 1 comment (--).



(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 splits normative and informative references.

There are no normative references to IDs.



(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 suggest a

reasonable name for the new registry? See [RFC2434]. 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 only requests assignment of additional values of

existing attributes, since most parameters were already allocated in

RFC 3575 and 3576.



(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?



This document does not contain sections written in a formal language.



(1.k) The IESG approval announcement includes a Document Announcement

Write-Up. Please provide such a Document Announcement Write-Up? Recent

examples can be found in the "Action" announcements for approved

documents. The approval announcement contains the following sections:



- Technical Summary



This document describes a currently deployed extension to the Remote

Authentication Dial In User Service (RADIUS) protocol, allowing

dynamic changes to a user session, as implemented by network access

server products. This includes support for disconnecting users and

changing authorizations applicable to a user session.



- Working Group Summary



This document represents an update to RFC 3576, addressing issues and

fixes that have been identified since the document was originally

published. Originally, these issues were included in the RADIUS Issues

and Fixes document, but were sufficient in number and size to require

a revision to RFC 3576.



- Document Quality



This document describes issues that were encountered by implementers of

RFC 3576. As a result, it has been reviewed by implementers as well as

operators.



- Personnel



David Nelson is the document shepherd. The responsible Area Director is

Dan Romascanu.