RADEXT Interim Meeting

Minute takers: Alexander, Hannes

Agenda Bashing and Status Update

3 WG documents adopted since the last IETF meeting, namely

• RADIUS v1.1
• TLS encryption for RADIUS
• TLS-PSK for RADIUS

Another document pending call for adoption: Deprecating insecure use of
RADIUS (RADIUS/UDP and RADIUS/TCP)

Chairs: Should we have another interim in June?

Mark: What is the status of the reverse CoA draft?

Alan: It expired but I will do an update. It is still work in progress.

WG Documents

TLS Encryption for RADIUS (Janfred)

draft6614bis

No update to the draft yet. Waiting for input from the group. Here are
the questions:

1) Do we want to merge RFC 6613 (RADIUS over TCP) and RFC 6614
(Transport Layer Security (TLS) Encryption for RADIUS)?

• Alan suggested to ignore RFC 6613. Janfred believes that some of the
  connection handling details are relevant for RADIUS over TLS.

2) What to do with RADIUS over DTLS? (RFC 7360)

• Janfred believes that it makes sense to merge these specs because of
  the similarities in the document content.
• Would be lots of overlap, but raises some problems around:
  • compliance, are you in compliance if an implementor supports TLS
    but not DTLS or vice versa
  • an implementor would see a document where though there is a lot
    of overlap, there may also be a lot of unnecessary information
    for them if only implementing one leg (eg. TLS but not DTLS)

Janfred presents 4 options:

• Leave draft6614bis as is.
• Include RFC 6613 but not RFC 7360
• Include RFC 7360 but not RFC 6613
• Merge all

Janfred prefers the 'merge all' option.

Alan: the only issue is the watchdog, etc. stuff in RFC 6613, which is
still needed in 6614, and also in 7360 (DTLS).

Margaret asks for views from the participants:

• Alan: Merge all is likely the best approach. We can have a section
  about connection issues, a section about DTLS, a section about the
  different between TLS and DTLS

  • TLS group prefer to treat the 'D' in DTLS silent and so the two
    are interchangable so probably should too

• Margaret: I can see it go both ways. I don't object to merging the
  two documents. It should still be possible that to claim conformance
  to TLS, DTLS or both. We have to be careful to not turn it into an
  overhaul on how to use TLS/DTLS in RADIUS.

• Valery: There is a lot of overlap between TLS and DTLS. Merging is a
  good idea.

• Hannes: importance of when implementing a stack should be
  accomplishable without a huge effort

• Alexander: Like the option of merging. It is a bit more work but
  worth it.

• Janfred: what should we do about allowing one or the other (DTLS or
  TLS)

  • Hannes: does not think you have to force someone to implement
    both

• Heikki: one specification would be good, but as there already exist
  implementations of TLS which do not support DTLS so allowing those
  platforms to continue would be helpful

• Alan [Zuplic]: good to suggest people do both, but should not
  require

  • Matthew Newton [Zulip]: 'Agreed'

• Margaret: I did not hear any object to the editor's preferred plan.
  Any objections?

• Valery: We have to confirm this on the list.

• Janfred will prepare a new version of the draft.

RADIUS Version 1.1 (Alan)

Alan goes through his slides.

ALPN negotiation is much easier in the logic side if you have the
end-user select via a flag on what to do when the server sees "radius
1.1"; forbid/require/allow

FIPS being a 'tickbox' it is easier to provide the machinery to allow
the banishment of MD5/MD5, and avoid argumnets/negioations with
auditors, but this standard does not force a site to do so if they need
to continue using authentication methods such as MS-CHAP

Document aims to be a description on how to take a 'RADIUS'
implemetation and make it a 'RADIUS 1.1' implementation and not cause
impact on prior or future attribute use and creation.

Alexander: On the ALPN negotiation, what are the flags?

Alan:

• allow (the new mechanism but also support the old one)
• require (the new)
• forbid (the old style)

Janfred: Slide says "Forbid cryptographic primitives in RADIUS". What
about new work on end-to-end security?

Alan: Perhaps this could be clarified. The goal is to forbid hop-by-hop
security, e.g. new ways of obfuscating data.

Janfred: A clarification would be good.

Janfred: Do we release these documents at the same time?

Margaret: Currently the milestones are different.

Alan: The status of this is also experimental.

Margaret: Are we ready for WGLC on this document?

Matthew: Forbidding crypto in the future: is this saying "RADIUS experts
should not design crypto."? Sounds a little bit tight.
The draft says "must implement TLS-PSK".

Alan: TLS-PSK - It was a strawman. Regarding Forbidding crypto there has
been a trend in the IETF to use TLS for everything. Once you define
crypto you have to add negotiation and other features. If you do this
you could as well use TLS.

Paul: You are not banning any new crypto mechanism. You are just using
TLS for communication security between neighboring nodes.

Alan: I will make a note about this.

Heikki: There was a discussion about the "secure bit". I believe this
does not fall under new crypto.

Alan: I put this in to say that this could be useful. Feedback from
Bernard Aboba (from the SIP community) said that this was useless. The
flag is informative and you cannot depend on it.

Heikki: Diameter also had e2e security but it was later removed.

Hannes: a quick note about Diameters experiences with the e2e
idea/implementation. The community did not see the need for it in the
end. Maybe the world though is now difficult and there is value in it.

Alan: This is also what Bernard says. If you don't trust the proxies,
then don't use them.

RADIUS and TLS-PSK

Problem with existing documents that mention TLS-PSK is an option, leave
it opaque on actually how an implementation should do this.

Purpose, public CAs are techically for browsers only (Browser Forum)
whilst private CAs are an administrative burden.

There is not much to this document, so one idea is to create a 'monster'
RADIUS 1.1 document and just throw it all in together.

This document is more an advisor on how to use and expose TLS-PSK for
implementors and users, as there is not really any technical to specify
here (already been done by the TLS group)

Margaret: curious if anyone has any thoughts on what to do with this

Alex: I see this as a standalone advisory ('RADIUS' could be swapped
with anything else) and has value standing on its-own

Josh: things this is going to be the most used model of plumbing RADIUS
servers together. As such it should be in the main document.

• Alan: nothing stops implementors grafting TLS-PSK onto an existing
  TLS implementation
• Josh: good point

Margaret: things 'and' in doing both, just release both rather than
delaying/gluing everything together. The document is simple so we could
get it out sooner, and then later also merge

• Alan: yes we could later merge it into the all singing-all-dancing
  RADIUS spec
• Margaret: as we are deprecating UDP it really would be helpful to
  have something to point others at to fill this space

Remaining work:

• only complexity to consider is that the PSK is not interchangable
  between TLS versions and so those PSKs must be unique
  • options: do we ignore the security problems of TLS 1.2 with PSK
    (and recycling between TLS versions) or just require TLS 1.3

Margaret: do we need to get a sec-reviewer to look at this

Paul W. (AD): yes we could get a sec-reviewer or someone from the TLS
working group to have a look

Margaret: going to arrage the feedback on the document

Proposed WG Documents

Deprecating RADIUS/UDP and RADIUS/TCP

Serious problems around Tunnel-Password's which in addition to privacy
and MD5 cracking, this needs to be deprecated.

Microsoft will not be working on NPS

• customers must keep with UDP/TCP
• alternatively move elsewhere

Margaret: we should tie this to 6614bis as deprecating UDP/TCP before
approving the replacement is a little awkward.

Alan: this is not deprecating TCP/UDP, but is deprecating their use in
'insecure' environment. The previous docs will not be put into
historical but having this as standards track means you can point to
"this is how we are meant to do RADIUS" rather than "you may wish to do
this"

Margaret: we may be able to do this as updating the standards track
documents instead.

Valery: Standards track or BCP? Why not BCP instead?

• Alan: that would be fine too
• Margaret: need to get Paul to sponsor this to be standards track

Alan: the bulk of cloud providers use UDP. Wants to try the 'marketing'
approach to try to persuade them to clean up their act

Margaret: WG hat off, day job has clients use a VPN to transport UDP to
their cloud service. TLS is not the only way to do this, IPsec works
too.

Michael Sym: likes that IPsec is not being deprecated. TLS debugging is
hard, do not want to lose visibility.

Alan: yes, debugging notes in the doc is needed. details about packet
contents and TLS frames is useful in FreeRADIUS to help users.

Request for WG Review

RADIUS profile for Bonded Bluetooth

Shipping today is roaming with BLE manufacturers but there is value in
having a RADIUS backed approach to roaming for interop.

The MQTT parts are planned to move into a separate document at some
later stage; this handles the comms between devices where non-IP is
used.

No EAP, but we assuming Bluetooth privacy.

Local configuration allows the device to change its MAC address every
second or every hour, whatever the local device configures..

The IRK/prand is used to test if the address is 'known'.

• outstanding issue is 24bits is not secure enough and something being
  worked on

Couple of new attributes are needed, in addition to an attribute type
for NAS-Port-Type

Questions:

Alan: possible DoS vector churning through the key space

Mark: awareness of cost of hashing on mobile devices and aware of
problems around the keying material

Margaret: question around spoofing using the same IRK/prand that was
observed?

Mark: IRK/prand is for the privacy address mapping back to 'known' but
another set of keying material is used for the actual data encryption.
You do get the DoS vector, but this would not let you get data moving

---

Pressed for time for the next meeting as no meetings may take place
within two weeks of IETF 117; so either last week of June or first week
of July

Janfred: may not be able to make it to IETF 117 or get the document
changes done in time

Maragret: first week of July awkward has US holidays, including own.

Janfred: will try to get the document ready and we should be able to get
the people on the list to work through the doc so no need for an
interim. Suggests a possible interim post IETF 117

Margaret: prefers not to have an interim, if people prefer we can
discuss at IETF 117 instead if we need an interim to clear things up
further?

• Alan: if we need another after July, we can add one

Margaret: plan is to meet next in San-Francisco and decide then if we
want to have a further interim.