[{"author": "Paul Wouters", "text": "

hello hello :)

", "time": "2023-05-22T14:00:42Z"}, {"author": "Hannes Tschofenig", "text": "

I can take a few notes during the first hour.

", "time": "2023-05-22T14:02:34Z"}, {"author": "Hannes Tschofenig", "text": "

(Have to leave after one hour)

", "time": "2023-05-22T14:02:46Z"}, {"author": "Alan DeKok", "text": "

One option might be to just ignore / drop 6613, as it is being deprecated?

", "time": "2023-05-22T14:12:07Z"}, {"author": "Alan DeKok", "text": "

we may also want to merge 7360 (RADIUS/DTLS), but I haven't compared the docs in detail

", "time": "2023-05-22T14:12:36Z"}, {"author": "Hannes Tschofenig", "text": "

my view: downrefs are not a problem. Just needs to be indicated in the shepherd write-up.

", "time": "2023-05-22T14:15:54Z"}, {"author": "Hannes Tschofenig", "text": "

you can be compliant to a spec even if you only implement one part of it. Needs to be clear in the spec though

", "time": "2023-05-22T14:16:14Z"}, {"author": "Alan DeKok", "text": "

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

", "time": "2023-05-22T14:18:11Z"}, {"author": "Paul Wouters", "text": "

(I have no strong preference)

", "time": "2023-05-22T14:21:05Z"}, {"author": "Valery Smyslov", "text": "

Do you want me to speak this to the mic?

", "time": "2023-05-22T14:22:01Z"}, {"author": "Alan DeKok", "text": "

It's good to suggest that people do both, I'd argue we don't need to require that they implement both

", "time": "2023-05-22T14:27:06Z"}, {"author": "Matthew Newton", "text": "

Agreed

", "time": "2023-05-22T14:28:08Z"}, {"author": "Paul Wouters", "text": "

that client looks very serverly :)

", "time": "2023-05-22T14:32:10Z"}, {"author": "Heikki Vatiainen", "text": "

Regarding combined Radsec spec: My guess is servers would be more likely to implement the DTLS and TLS while clients may have more specific uses where just one variant is good enough

", "time": "2023-05-22T14:33:42Z"}, {"author": "Jan-Frederik Rieckers", "text": "

@heikki good point. I'll keep it as SHOULD do both, but MUST only do one of the two

", "time": "2023-05-22T14:34:25Z"}, {"author": "Matthew Newton", "text": "

sorry can't see how to get off mute!

", "time": "2023-05-22T14:45:45Z"}, {"author": "Hannes Tschofenig", "text": "

Matthew - microphone problems?

", "time": "2023-05-22T14:45:45Z"}, {"author": "Valery Smyslov", "text": "

THe mic sign above the list of participants

", "time": "2023-05-22T14:46:11Z"}, {"author": "Matthew Newton", "text": "

thanks found it

", "time": "2023-05-22T14:46:20Z"}, {"author": "Valery Smyslov", "text": "

Just click on it

", "time": "2023-05-22T14:46:20Z"}, {"author": "Paul Wouters", "text": "

I guess \"do the PQ in TLS, not in radius\" ?

", "time": "2023-05-22T14:47:36Z"}, {"author": "Jan-Frederik Rieckers", "text": "

Basically the intention is: TLS people know their stuff, don't try to invent your own things.

", "time": "2023-05-22T14:48:25Z"}, {"author": "Hannes Tschofenig", "text": "

I unfortunately have to leave. Good meeting.

", "time": "2023-05-22T14:55:56Z"}, {"author": "Alexander Clouter", "text": "

\"SHIP IT!\"

", "time": "2023-05-22T14:55:57Z"}, {"author": "Alexander Clouter", "text": "

:)

", "time": "2023-05-22T14:55:59Z"}, {"author": "Matthew Newton", "text": "

I've been through it a few times, have a few more typos but otherwise all happy with it.

", "time": "2023-05-22T14:56:17Z"}, {"author": "Alexander Clouter", "text": "

Alan obviously does not love his spellchecker :)

", "time": "2023-05-22T14:56:29Z"}, {"author": "Jan-Frederik Rieckers", "text": "

Jan 2024 6614bis and 7360bis to IESG draft-rieckers-radext-rfc6614bis
\nSep 2023 TLS-PSK Best Practices draft-dekok-radext-tls-psk

", "time": "2023-05-22T15:01:21Z"}, {"author": "Alan DeKok", "text": "

It's really just documenting administration interfaces

", "time": "2023-05-22T15:02:37Z"}, {"author": "Jan-Frederik Rieckers", "text": "

+1

", "time": "2023-05-22T15:06:08Z"}, {"author": "Mark Donnelly", "text": "

+1

", "time": "2023-05-22T15:06:16Z"}, {"author": "Paul Wouters", "text": "

yes, this is not really Experimental anymore :)

", "time": "2023-05-22T15:14:14Z"}, {"author": "Valery Smyslov", "text": "

Standards track or BCP?

", "time": "2023-05-22T15:14:53Z"}, {"author": "Paul Wouters", "text": "

it is something \"new\", so i would argue it is not BCP ?

", "time": "2023-05-22T15:17:35Z"}, {"author": "Jan-Frederik Rieckers", "text": "

+100

", "time": "2023-05-22T15:21:31Z"}, {"author": "Paul Wouters", "text": "

(for IKEv1 and IKEv2, people were running both and we wanted to move them to IKEv2. that is more BCP like but we still decided to mark IKEv1 as Historic to push peope a bit harder to IKEv2.But here, as Alan points out, it is far worse. The current deployment without TLS is basically broken. It needs a very strong MUST for transport encryption.

", "time": "2023-05-22T15:22:47Z"}, {"author": "Paul Wouters", "text": "

i feel the RFC without transport security should be obsoleted

", "time": "2023-05-22T15:23:24Z"}, {"author": "Matthew Newton", "text": "

ALPN doc has good comments saying debugging is recommended.

", "time": "2023-05-22T15:25:09Z"}, {"author": "Alexander Clouter", "text": "

Michael: if you control the client or server, you can gain the plaintext of the TLS data and dig through it all in Wireshark

", "time": "2023-05-22T15:25:42Z"}, {"author": "Alan DeKok", "text": "

Matthew: good point... maybe I can use that in the deprecating doc.

", "time": "2023-05-22T15:28:18Z"}, {"author": "Michael Sym", "text": "

thanks, Alex: do you mean you can gain that at the application level, which can then log it? running a pcap on the box would have that whole exchange encrypted.

", "time": "2023-05-22T15:29:18Z"}, {"author": "Matthew Newton", "text": "

Alan: Sounds good, I would put comments about debug output everywhere. Software that doesn't tell you what it's doing is infuriating.

", "time": "2023-05-22T15:29:56Z"}, {"author": "Alan DeKok", "text": "

OpenSSL can export the TLS session information in a key file. Wireshark can read that information to decrypt the TLS session

\n

See https://everything.curl.dev/usingcurl/tls/sslkeylogfile for an example. FreeRADIUS does the same thing

", "time": "2023-05-22T15:33:18Z"}, {"author": "Michael Sym", "text": "

Got it, thanks for the link. Agree this is helpful when controlling the client or server as an admin. For debugging we often need both the client and server side.

", "time": "2023-05-22T15:39:41Z"}, {"author": "Michael Sym", "text": "

We see a lot more native RadSec support on equipment like APs these days, where full admin control may not be available.

", "time": "2023-05-22T15:40:09Z"}, {"author": "Alexander Clouter", "text": "

https://gist.github.com/jimdigriz/327ef6afa808a1b291d12d68857dec05

", "time": "2023-05-22T15:40:23Z"}, {"author": "Alexander Clouter", "text": "

for the TLS decoding

", "time": "2023-05-22T15:40:32Z"}, {"author": "Alexander Clouter", "text": "

I think Radiator supports something like dumping the keys and hostapd does (behind a compile flag)

", "time": "2023-05-22T15:41:01Z"}, {"author": "Heikki Vatiainen", "text": "

Radiator can also dump the keys in SSLKEYLOGFILE format. It's become really useful with TLSv1.3

", "time": "2023-05-22T15:47:21Z"}, {"author": "Michael Sym", "text": "

Thanks, Alex and Heikki! Heikki, is that documented in the latest ref.pdf?

", "time": "2023-05-22T15:48:19Z"}, {"author": "Jan-Frederik Rieckers", "text": "

I won't be in San Francisco (and may not be able to join remotely)

", "time": "2023-05-22T15:48:21Z"}, {"author": "Paul Wouters", "text": "

there were thoughts on standardizing SSLKEYLOGFILE, but people got really nervous some will use it as backdoor mechanism on production units.

", "time": "2023-05-22T15:48:27Z"}, {"author": "Alexander Clouter", "text": "

I fixed up the EAP TLS decoding for RADIUS, so you can go all the way down

", "time": "2023-05-22T15:48:30Z"}, {"author": "Alexander Clouter", "text": "

I discovered EAPOL decoding is bust again, but EAP over RADIUS is fine; as RADIUS over TLS should be fine too

", "time": "2023-05-22T15:49:02Z"}, {"author": "Paul Wouters", "text": "

If meeting in july, remember you cannot meet within two weeks of IETF 117

", "time": "2023-05-22T15:49:12Z"}, {"author": "Alan DeKok", "text": "

so it would have to be June. With 2 weeks advance notice needed, pretty much only last 2 weeks of June would be allowed

", "time": "2023-05-22T15:50:40Z"}, {"author": "Paul Wouters", "text": "

The list seems low key enough to actually get work done without interims

", "time": "2023-05-22T15:51:49Z"}, {"author": "Alan DeKok", "text": "

If we need another interim after July, we can always add one.

", "time": "2023-05-22T15:55:13Z"}, {"author": "Jan-Frederik Rieckers", "text": "

+1

", "time": "2023-05-22T15:55:29Z"}, {"author": "Paul Wouters", "text": "

I love pinball :)

", "time": "2023-05-22T15:55:38Z"}, {"author": "Heikki Vatiainen", "text": "

Michael search for SSLKEYLOGFILE in ref.pdf. It's available for EAPs and Radsec

", "time": "2023-05-22T15:55:50Z"}, {"author": "Alexander Clouter", "text": "

Michael, you need Wireshark 4.0 or later to decode EAP types too

", "time": "2023-05-22T15:57:24Z"}]