Minute takers: Alexander, Hannes
3 WG documents adopted since the last IETF meeting, namely
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.
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)?
2) What to do with RADIUS over DTLS? (RFC 7360)
Janfred presents 4 options:
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
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)
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
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.
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:
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.
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.
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
Remaining work:
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
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
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: 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.
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'.
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?
Margaret: plan is to meet next in San-Francisco and decide then if we
want to have a further interim.