Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
draft-ietf-radext-coa-proxy-10

[Ballot comment]
I'm clearing my DISCUSS based on discussion over email and in the telechat. I am happy to leave the outcome to Benjamin's discretion. I'm including the original text below for reference:


(This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..)

This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC.



Thanks for a readable and understandable drafts. I have some additional comments that do not rise to the level of a DISCUSS

Substantive Comments:

- I support Adam's DISCUSS point concerning the security properties of Operator-NAS-Identifier. But I will let that play out in Adam's thread.

§3.1 and §3,3: Do the normative changes to Access-Request and Accounting-Request mean that this draft needs to update documents other than just RFC 5176?

Editorial Comments:

- The abstract and introduction explain how this draft updates 5176, which is good. However, they avoid using the explicit term-of-art "Updates RFC 5176". Doing so would help make things more explicit. (The RFC style guide recommends doing this at least in the abstract.)

- Please expand PPTP and L2TP on first mention.

§3.1: I suspect some of the normative keywords in this section refer to previously existing requirements rather than new requirements. If  so, they should not be capitalized except in literal quotes.

§6: I think it would be helpful to mention the discussion in §4.3 in the security considerations.

§7: It would be helpful for the IANA considerations to briefly summarize the new attributes, so that a reader that started out reading the IANA considerations doesn't have to flip back to §3.3 just to find out what they are.

[Ballot comment]
Just a minor comment, the intended status is STD Track but the footer says Informational. The disconnect will need to be resolved at some point.

-m

[Ballot comment]
Thanks for a readable and understandable drafts. I have some additional comments that do not rise to the level of a DISCUSS

Substantive Comments:

- I support Adam's DISCUSS point concerning the security properties of Operator-NAS-Identifier. But I will let that play out in Adam's thread.

§3.1 and §3,3: Do the normative changes to Access-Request and Accounting-Request mean that this draft needs to update documents other than just RFC 5176?

Editorial Comments:

- The abstract and introduction explain how this draft updates 5176, which is good. However, they avoid using the explicit term-of-art "Updates RFC 5176". Doing so would help make things more explicit. (The RFC style guide recommends doing this at least in the abstract.)

- Please expand PPTP and L2TP on first mention.

§3.1: I suspect some of the normative keywords in this section refer to previously existing requirements rather than new requirements. If  so, they should not be capitalized except in literal quotes.

§6: I think it would be helpful to mention the discussion in §4.3 in the security considerations.

§7: It would be helpful for the IANA considerations to briefly summarize the new attributes, so that a reader that started out reading the IANA considerations doesn't have to flip back to §3.3 just to find out what they are.

[Ballot comment]
S 3.3.

>      The new Operator-NAS-Identifier attribute is defined as follows.

I suggest adding the depiction of the fields and their lengths in
bytes, as is done in RFC 5580. I was a little confused about whether
the fields in the attribute are just the TLV.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5085


I concur with Adam's DISCUSS (but marking no-objection to let him
manage this). Specifically, you need to describe what the security
expectations are for the Operator-NAS-Identifier. Need it be
unguessable? Should separate identifiers that refer to the same NAS be
unlinkable? "Cryptographically strong" is not a sufficiently specific
term to determine what the requirements are here.

COMMENTS
S 6.
>      issues.
> 
>      The Operator-NAS-Identifier SHOULD be created by the Visited Network
>      such that its contents are opaque to all other parties.  This ensures
>      that anyone observing unencrypted RADIUS traffic gains no information
>      about the internals of the Visited Network.

See above about the requirements here. Does there need to be an
unlinkable identifier each time?

[Ballot discuss]
(This is a procedural DISCUSS. Hopefully it can be resolved easily, but I do think it needs to be resolved prior to publication..)

This draft is standards track, yet it primarily serves to extend RFC 5176. That RFC is informational. The shepherd writeup argues that this is okay because it seems like 5176 should have been standards track. But the applicability statement RFC 5176 explains why it was informational, and the reasons seem convincing. Therefore I do not think it is appropriate to publish this draft as Standards Track. I think it would be fine to progress it as Informational (or even Experimental) if it included an applicability statement explaining why in order to avoid the appearance of a standard masquerading as an Informational RFC.

[Ballot comment]
(My review is not yet complete; I wanted to get the DISUSS point out with as much discussion time as possible. I expect to follow up with an update sometime before the telechat.)

[Ballot discuss]
Thanks for the quick response on the looping concern I thought might exist.
The original text for my other concern appears below.

§4.2:

>  The value SHOULD be cryptographically strong, and SHOULD be
>  verifiable by the Visited Network, without requiring it to track in a
>  database every individual value of Operator-NAS-identifier which was
>  issued.

I don't think this is really phrased in a way that means what you want to say.
If I had to guess, you mean to say that the value must be encrypted, and that it
must be integrity-protected. If integrity protection is important, then you also
need to consider techniques to avoid replay of previously-seen tokens (e.g., the
integrity protection needs to be over not just the Operator-NAS-Identifier,
but also over some portion of the session that prevents its replay). Most
notably, this desire for encryption and integrity protection is almost
certainly at odds with the assertion (in §3.3) that "A twenty octet string is
more than sufficient to individually address all of the NASes on the planet."
For example, the naïve approach of appending a SHA-256 hash to the end of an
encrypted, salted index into a table of NAS devices would require over 32 bytes
at its absolute minimum. So, if integrity protection is something that any
operator might ever want, you need to revisit the 20-byte limit.

>  Exactly how this requirement is implemented is outside of the scope
>  of this document.

That's fair, but I think you need a proof-of-concept example of how it could be
done, so that you find any additional corner cases beyond the one I've
identified above.

I think these aspects of this attribute need a lot more treatment in Section 6.

[Ballot discuss]
I'd like to thank the author and all other involved parties for the work that
has gone into making CoA transactions work across multiple domains. I have a
couple of DISCUSS points that I think need to be cleared up.

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

This is a concern with the general mechanism, and might be due to a
misunderstanding on my part (which I hope you can clear up); but if I'm not
wrong, then I'm concerned that the mechanism as described can introduce RADIUS
message routing loops in some very common deployment scenarios.

Consider a setup involving three networks: a Visited network (with its NAS and
a Radius server), a Clearinghouse network (with one or more proxies), and a
Home network (with a border proxy and a Home Server). Both the Home and Visited
network also have federated networks that they communicate directly with without
traversing the Clearinghouse network.

The Clearinghouse determines the destination of any request message by looking
at the realm portion of the NAI present in the "User-Name" attribute, which I
believe is pretty common routing logic in these kinds of cases.

Now, consider what happens when the Home network updates to use this mechanism
(in order to better work with their federated partners), and the Visited network
also updates to use this mechanism (for the same reason), but the Clearinghouse
is not yet updated. I'll try to step through section 5 with this scenario:

1) The NAS in the Visited network sends an Access-Request packet to the
  Visited Radius server. The visited RADIUS server will see that the
  user is roaming, and will add an Operator-Name attribute, with value
  "1" followed by it's own realm name.  e.g. "1example.com".

2) The visited RADIUS server will then proxy the authentication request
  to the Clearinghouse network, which uses the NAI in the User-Name to forward
  it to the Home network.

3) The Home Server records the Operator-Name along with other information
  about the users session

4) When the Home Server determines that a user should be disconnected,
  it looks up the Operator-Name, along with other user session identifiers as
  described in [RFC5176].

5) The Home Server sends the Disconnect-Request to the Home domain's border
  proxy.

6) The Home domain's border proxy looks up the Operator-Name in the
  Disconnect-Request message, determines that it is an operator that it is
  not federated with, and consequently sends the Disconnect-Request to the
  Clearinghouse.

7) The Clearinghouse receives the Disconnect-Request message. Since it has not
  yet been updated to handle the Operator-Name attribute as described in this
  document, it follows its normal logic of routing according to the NAI in the
  User-Name attribute.

8) Go to 6

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

§4.2:

>  The value SHOULD be cryptographically strong, and SHOULD be
>  verifiable by the Visited Network, without requiring it to track in a
>  database every individual value of Operator-NAS-identifier which was
>  issued.

I don't think this is really phrased in a way that means what you want to say.
If I had to guess, you mean to say that the value must be encrypted, and that it
must be integrity-protected. If integrity protection is important, then you also
need to consider techniques to avoid replay of previously-seen tokens (e.g., the
integrity protection needs to be over not just the Operator-NAS-Identifier,
but also over some portion of the session that prevents its replay). Most
notably, this desire for encryption and integrity protection is almost
certainly at odds with the assertion (in §3.3) that "A twenty octet string is
more than sufficient to individually address all of the NASes on the planet."
For example, the naïve approach of appending a SHA-256 hash to the end of an
encrypted, salted index into a table of NAS devices would require over 32 bytes
at its absolute minimum. So, if integrity protection is something that any
operator might ever want, you need to revisit the 20-byte limit.

>  Exactly how this requirement is implemented is outside of the scope
>  of this document.

That's fair, but I think you need a proof-of-concept example of how it could be
done, so that you find any additional corner cases beyond the one I've
identified above.

I think these aspects of this attribute need a lot more treatment in Section 6.

[Ballot comment]
All of my comments are editorial nits.

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

ID Nits reports:

  ** The abstract seems to contain references ([RFC7542]), which it
    shouldn't.  Please replace those with straight textual mentions of the
    documents in question (e.g., "RFC 7542").

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

§2.1:

>  Other methods are
>  possible, but we restrict ourselves to this usage, as it is the most
>  common one.

This needs to be clear whether the *description* is restricted to NAI-based
routing, or whether the *mechanism* is. I suspect it's the former; in any case,
please add text.

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

§2.1:

>  Once
>  a response has been received by the proxy, it can discard all
>  information about the request packet.

Nit: "Once a response has been sent by the proxy..."
                              ^^^^

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

§3.2:

>  We therefore need a way to identifier a NAS in the Visited Network,

Nit: "...to identify a NAS..."

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

§3.3:

>  We suggest that the contents of the NAS-Identifier be the Realm name
>  of the Visited Network.  That is, for everyone outside of the Visited
>  Network, there is only one NAS: the Visited Network itself.  For the
>  Visited Network, the identity of the NAS is private information,
>  which is opaque to everyone else.

Please be clear that this recommendation is for the (existing) NAS-Identifier
attribute rather than the (new) Operator-NAS-Identifier attribute.

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

§3.3:

>    This token MUST allow the Visited Network to direct the packet to
>    the NAS for the users session.

Nit: "...user's session..."

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

§4.2:

>  CoA server (i.e. NAS).  This requirement is phrase more generically
>  below, in Section 4.3.2.

Nit: "...phrased..."

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

§4.3.1:

>  it SHOULD return a
>  CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause
>  attribute having value 503 ("Session Context Not Found").

Nit: "...packet that contains..."

[Ballot comment]
Thanks for this well-written doc.

One nit in sec 3.1: s/activee/active/

One quick question on sec 3.3:
"Operator-NAS-Identifier MUST NOT occur more than once in a packet."
What happens if it occurs more than once? Just ignore or send an error?

[Ballot comment]
Thanks for this well written doc.

One nit in sec 3.1: s/activee/active/

One quick question on sec 3.3:
"Operator-NAS-Identifier MUST NOT occur more than once in a packet."
What happens if it occurs more than once? Just ignor or send an error?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-radext-coa-proxy-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the RADIUS Attribute Types registry on the RADIUS Types reigstry page located at:

https://www.iana.org/assignments/radius-types/

a single, new attribute is to be registered as follows:

Value: [ TBD-at-Registration ]
Description: Operator-NAS-Identifier
Data Type: extended
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-13):

From: The IESG
To: IETF-Announce
CC: radext@ietf.org, stefan.winter@restena.lu, draft-ietf-radext-coa-proxy@ietf.org, radext-chairs@ietf.org, kaduk@mit.edu, Stefan Winter
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS)) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document: - 'Dynamic Authorization Proxying in Remote
Authorization Dial-In User
  Service Protocol (RADIUS)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  RFC 5176 defines Change of Authorization (CoA) and Disconnect Message
  (DM) behavior for RADIUS.  Section 3.1 of that document suggests that
  proxying these messages is possible, but gives no guidance as to how
  that is done.  This specification corrects that omission for
  scenarios where networks use Realm-based proxying as defined in
  [RFC7542].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-radext-coa-proxy/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational - IETF stream)

draft-ietf-radext-coa-proxy-04.txt
==================================

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The document aims at Standards Track, and this is indicated in the header. The document defines new RADIUS attributes and an algorithm for their use which enable the use of RFC5176-style Change of Authorization (CoA) and Disconnect (DM) messages in large proxy-based roaming environments, so long as these environments are able to identify clients with a domain name.

Considering that RFC5176 itself is Informational, one could reason about the document at hand also being Informational. However, it appears rather the other way around, namely that RFC5176 is rather misplaced at Informational and with its rather normative nature should better have been Standards Track.

(2) 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:

  RFC 5176 defines Change of Authorization (CoA) and Disconnect Message
  (DM) behavior for RADIUS.  Section 3.1 of that document suggests that
  proxying these messages is possible, but gives no guidance as to how
  that is done. This ommission means that proxying of CoA packets is,
  in practice, impossible. This specification corrects that omission for
  scenarios where networks use Realm-based proxying as defined in
  [RFC7542].
  It leverages an existing RADIUS attribute, Operator-Name ( Section
  4.1 of [RFC5580]), to record the visited network for a particular
  session.  The document explains how that attribute can be used by CoA
  proxies to route packets "backwards" through a RADIUS proxy chain. It
  introduces a new attribute; Operator-NAS-Identifier, and shows how this
  attribute can increase privacy about the internal implementation of
  the visited network.
 
Working Group Summary:

  The radext working group is rather light in attendance and discussion,
  and will shut down soon. With that said, this particular document got
  a (comparatively) good amount of review and interest.

Document Quality:

At least one RADIUS implementation has support for parts of this specification. Particularly the bit about replacing NAS-IP-Address/IPv6-Address/NAS-Identifier with Operator-NAS-Identifier when leaving the own administrative domain is not implemented. The complexity of that functionality can be expected to be modest, though.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

The Document Shepherd is Stefan Winter . The responsible area director is Benjamin Kaduk .

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd reviewed the document continuously throughout its lifecycle from individual submission to the current rev. For the write-up at hand, the shephard did another fresh read of -03. The document contained one item worth clarifying and the author submitted a version -04 to address these.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The usual WG constraints in terms of available manpower to review specs apply.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document addresses is a core RADIUS question without significant external dependencies.

(6) Describe any specific concerns or issues that the Document Shepherd has 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 specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

One author confirmed on the radext mailing list during WGLC, another in a private mail to the document shepherd.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There is no IPR disclosure on record.

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

Within the previously stated limitations, the working group stands behind this document.

(10) 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 publicly available.)

No appeal was threatened. Some working group participants find it suboptimal that the document is scoped only towards realm-based scenarios; the answer is that if any other proxy mechanisms are to be covered, then those should be published in their own document.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)
   
(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review besides IDNITs and the present shephard review are required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) 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 plan for their completion?

All normative references are issued RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

According to IDNITs, none of the references are downward references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document updates RFC5176, and this is indicated in the header.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There is an IANA action to register a new RADIUS attribute. The corresponding instructions are clear.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document asks for a new attribute in the RADIUS attributes registry. The assignment requires Standars Action, which this document triggers.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no such sections.