[secdir] SecDir review of draft-ietf-radext-coa-proxy

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 13 August 2018 21:16 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 04D981310D1; Mon, 13 Aug 2018 14:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HGXoBOKaTdJg; Mon, 13 Aug 2018 14:16:35 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D191310CF; Mon, 13 Aug 2018 14:16:35 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id b15-v6so29796818oib.10; Mon, 13 Aug 2018 14:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nq9r8Ze7P8GD3y7EIYY35SJOuw+NIITKMjDWnWteNkY=; b=ISRkIBMIRml9AzFxD7efDKvpWJFBDmXpzVpOORqm9cEzShrMrAOvSdzi1whMrBPXPH xsnRfVleYcqUV7zl29ntmr3XjqbeMsPHNxtSAY+wFy3xyTsocbjoQhUse2RmstXVqXgC FB/VGQp2t7hpRMM79fnzCuoHyvmGHSJbQ+rTMPwZnl+sw/lCHDbkip4Xfnfi2DcM4wHc JYsDrX8p2vkSKRb69FWvJ2Cf33g1q6mTMXkfzUWqqzyX09mbVPS+ozGsj52EQZ+8ECDt tz8acQT4kySafRTuqlwFlIi65ri9fnvHb2vynpKkp742617l6ek/ZECnamK4t49tlS+C DlMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nq9r8Ze7P8GD3y7EIYY35SJOuw+NIITKMjDWnWteNkY=; b=Gpo1aWFuALbaamzd23LcnBV0MnYAtskSXMaV4A+SPCYKTwfTT5BYCpR21+IdocIkyK I6oIqK7M3ps9JqIxPzCEzkSconZPU2BBdDeEDKy/uKtYxLBdQUwyuWDDQnse6IGCkSst /7RSlimSGEk2evzpsAqYzOsaJv18li6ZGKGsCWNlwRRQ4mNUbQRIUXJz+H1WqEALm6cG YBhueB81VJZmnbdTPvVBmLYsS6jLTUS2LZxgRcBo5LKnvqbUvJptKP+Q2e0O67+h42Gv bTp/On2G7n+libbw98R9ElXLrhV570HeNSWvMlm5AMF79WnL6dSBkdGrSpZjleXuCiAA SmiA==
X-Gm-Message-State: AOUpUlGUfyyuUuR9VCgP7Fl1fF78tNu+cKrMIT9qe8xw52varJRPL7tU ba977dSS5QTlAVgwZ3O5bXWtLiCO4vPBwiF4RVgYWLN/
X-Google-Smtp-Source: AA+uWPwvlbKpGGROBrSAag5sSSJTSBW/zSpnIwMI4WYjiD8mq++hiH8DNQxdO5zYbWh2ds5j0kX4Yt1GGjyvst59Y18=
X-Received: by 2002:aca:db09:: with SMTP id s9-v6mr20818684oig.339.1534194995103; Mon, 13 Aug 2018 14:16:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 14:15:54 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 13 Aug 2018 17:15:54 -0400
Message-ID: <CAHbuEH5q-uU9O-ikn4v=ua7M3N7fVhFt4DAWkrWjbunwJJQZig@mail.gmail.com>
To: draft-ietf-radext-coa-proxy.all@tools.ietf.org, IESG <iesg@ietf.org>, IETF SecDir <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b30d4f0573579b53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/e-RyoEbRcn5ChuEL8-wxMfPLA8g>
Subject: [secdir] SecDir review of draft-ietf-radext-coa-proxy
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 21:16:38 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
 Document editors and WG chairs should treat these comments just like any
last call comments.

The summary of the review is that this document is ready with some
editorial fixes.

Thanks for your work on this draft!  If this is the last draft, which I
think it may be, I am really glad I got to review it to see the last one
for the WG.  Congratulations!!!

Here's my review:

In the abstract, it reads as though RFC7542 is updated by this draft with
the text that says,
"This specification corrects that omission for
   scenarios where networks use Realm-based proxying as defined in

The text in the introduction on these two draft is a bit more clear in that
RFC7542 defines a use case that requires this update to RFC5176.  I think
it would be helpful to expand the abstract text to make these points more
clear to the reader.

Nit Section 3.1:

Section 3.3:

A sentence like the following seems to invite it to be proved wrong at some
point ;-).

      A twenty octet string is
      more than sufficient to individually address all of the NASes on

DeKok, Alan                   Informational                    [Page 10]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS    30 July 2018

      the planet.

Perhaps a statement that says it is believed this will be sufficient given
current deployment trends may read better and not tempt fate. :-)

Section 4.3.1

For the following paragraph:
   Proxies that record user session information SHOULD verify the
   contents of a received CoA packet against the recorded data for that
   user session.  If the proxy determines that the information in the
   packet does not match the recorded user session, it SHOULD return a
   CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause
   attribute having value 503 ("Session Context Not Found").
Are there privacy recommendations that have already been made to leave out
certain user information, obscure it, or protect it in some way?  If so, a
pointer to that documentation would be a nice addition.  If not, a pointer
to RFC6793 would be helpful.

Section 6.

The ability to attack, intercept or inject data into RADIUS sessions should
be mentioned as a security consideration.  Is there an RFC that explains
how sessions can be encrypted that can be referenced (TLS for server to
server connections and DTLS for client)?  If not, I think it's worth adding
a sentence so that people are aware of these options even if they don't
care to implement them.


Best regards,