Re: [radext] I-D Action: draft-dekok-radext-deprecating-radius-04.txt

["Mark Grayson (mgrayson)" <[e-mail]>]

Hi Alan

Regarding the text around location in 7.1

> Location information ([RFC5580] SHOULD either be omitted, or else it
> SHOULD be limited to the broadest possible information, such as
>  country code.  For example, [I-D.tomas-openroaming] says:
>
>      All OpenRoaming ANPs MUST support signalling of location
>      information
>
>  This location information is required to include at the minimum the
>  country code.  We suggest the country code SHOULD also be the maximum
>  amount of location information which is sent over third-party
>  networks.

Just to be clear, I-D.tomas-openroaming includes other use cases, e.g.,
where country code maybe insufficient.

> When the OpenRoaming ANP supports the OpenRoaming-Settled RCOI ("BA-
> A2-D0"), the Location-Data attribute (#128) MUST be included where
> the location profile is the civic location profile containing Civic
> Address Type information that is sufficient to identify the financial
> regulatory regime that defines the taxable rates associated with
> consumption of the ANP's service.¶<https://datatracker.ietf.org/doc/html/draft-tomas-openroaming-00#section-8.3-2>

In terms of which terms control the use of location, 5580 seems to assume
that the access network provider can define those controlling terms and can
define restrictions, e.g., using the Retransmission Allowed setting in an
Access-Request.

Instead, the more typical approach is that use of location is covered in the
terms agreed between an end-user and their credential provider/AAA server
operator. This then would be reflected as a 5580 out-of-band agreement, ensuring
that the user is fully aware of the use of any location which is sent over third
party networks. With such a scenario, it is not obvious how a single access network
provider can define a single restrictive policy when interconnecting with
multiple credential holders that may have agreed different terms with their end-users.

Best regards,
Mark



From: radext <[e-mail]> on behalf of Alan DeKok <[e-mail]>
Date: Wednesday, 27 September 2023 at 21:07
To: [e-mail] <[e-mail]>
Subject: Re: [radext] I-D Action: draft-dekok-radext-deprecating-radius-04.txt
  This revision makes it clearer that the focus is not just UDP/TCP, but deprecating all insecure practices in RADIUS.

  It adds substantial text on MS-CHAP, and on other security issues.

> On Sep 27, 2023, at 4:04 PM, [e-mail] wrote:
>
> Internet-Draft draft-dekok-radext-deprecating-radius-04.txt is now available.
> It is a work item of the RADIUS EXTensions (RADEXT) WG of the IETF.
>
>   Title:   Deprecating Insecure Practices in RADIUS
>   Author:  Alan DeKok
>   Name:    draft-dekok-radext-deprecating-radius-04.txt
>   Pages:   34
>   Dates:   2023-09-27
>
> Abstract:
>
>   RADIUS crypto-agility was first mandated as future work by RFC 6421.
>   The outcome of that work was the publication of RADIUS over TLS (RFC
>   6614) and RADIUS over DTLS (RFC 7360) as experimental documents.
>   Those transport protocols have been in wide-spread use for many years
>   in a wide range of networks.  They have proven their utility as
>   replacements for the previous UDP (RFC 2865) and TCP (RFC 6613)
>   transports.  With that knowledge, the continued use of insecure
>   transports for RADIUS has serious and negative implications for
>   privacy and security.
>
>   This document formally deprecates using the User Datagram Protocol
>   (UDP) and of the Transmission Control Protocol (TCP) as transport
>   protocols for RADIUS.  These transports are permitted inside of
>   secure networks, but their use in secure networks is still
>   discouraged.  For all other environments, the use of secure
>   transports such as IPsec or TLS is mandated.  We also discuss
>   additional security issues with RADIUS deployments, and give
>   recommendations for practices which increase security and privacy.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-dekok-radext-deprecating-radius/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-dekok-radext-deprecating-radius-04.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-dekok-radext-deprecating-radius-04
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/radext