IETF 121, Dublin
Monday, November 4, 2024, 17:30 - 19:00 GMT/UTC
Chairs: Margaret Cullen, Valery Smyslov
Note taker: Alan DeKok, Ethan Thompson
### Status update for documents in progress (Alan, 5 min)
Heikki has conducted tests for Draft-ietf-radext-tls-psk and has not run
into issues. More tests should be conducted.
Margaret suggests that we can do a WG last call on "deprecating insecure
practices"
Some discussions on the TLS-PSK document, minor feedback on session
resumption. Valery points out that if the draft changes, it has to go
back to the WG to get WG consensus. Perhaps on discussion with AD, we
don't need to do this.
Alan will summarize the proposed changes on the list, and the chairs
will discuss with Paul. If the changes are minimal, then it should be
OK.
Heikki - the deprecating insecure practices is long, can it be shorter?
Alan - I don't know how :(
Margaret - It's valuable to document this extensively.
Janfred - maybe move some of the explanation of issues to the appendix,
and have the actual normative text in the main body. Goal is to keep the
text of the RFC straight forward by cutting deeper explanations which
readers may skip.
Margaret - doesn't see the value in labeling these sections as
"appendix". We should try to get this RFC out faster so others can
reference it.
Alan - alright with moving things to an appendix, though without the
explanations as to why a decision or recommendation was made, readers
may not care to follow the docs.
Janfred - Regarding the explanation of what is wrong: recommends
shortening this text in the normative section, and expand on it in an
appendix for readers to find, keeping the normative text concise.
Valery - Asks working group to review thses drafts with attention to the
MAY's and MUST's so that we can move forward with progress on this
draft.
Margaret - looking for volunteers to review the draft.
Alan - on the reverse CoA doc: it is essentially done... there has been
no major comments from reviewers. Could do a WG last call and be done
with it.
### (Datagram) Transport Layer Security (D)TLS Encryption for RADIUS
(Janfred, 40 min)
draft-ietf-radext-radiusdtls-bis
Updates - Since IETF 120:
Results from the interum meeting:
Proxying and load balancing considerations are deemed to be out of
scope for this doc. This includes
Dealing with unwanted packets (i.e., Accounting) needs some more
thought (e.g., is it out of scope?)
In regards to the selfie attack:
Attack precondition: RADIUS/(D)TLS has an aligning config for
client/server
Attacker could mirror TLS traffic back to the same server and casue
a loop
Proposed countermeasures:
Option 2: Check client random received in TLS handshake if equal
to some own client random
Option 3: Use Status-Server message to send a peer ID, as first
packet
Fabian - All measures proposed are only first line of defenses.
Multi-line hop breaks this down. Loop prevention has been proposed, this
could be used here. Recommendations could be added. Final solution
should be status realm loop prevention including the hops.
Jonathan - correct measure would be a mix of option 1 and RFC 9257.
Janfred - Will look at RFC 9257
Alan - for the issue of bad packets, we should do the same thing as the
proxy issue: mention it in the doc, and that's it. Mention that loop
prevention is out of scope for this doc. Detecting the selfie attack and
loops - if inbound is greater than outbound, something could be done on
the administrator side.
Alex - Looked at RFC 9257. One of the suggestions in the rfc, using
client ID's, may not work well with multiple boxes.
Margaret - If we don't have anything to say and add on the issue, it may
be best to not talk too much about it. Just say something like "this
issue is no worse than what already exists in TLS" and ref the TLS docs.
Document the fact that we haven't fixed this issue, and ref other docs
DTLS records and RADIUS packet:
There is no explicit specification on how RADIUS packets are put
into TLS records.
We should add explicit specification on how to send RADIU packets
for DTLS. TLS is a stream anyway, so no need to specify.
Do we have experience with existing DTLS implementations? Are they
doing it? Do the TLS libraries provide this interface or are they
doing some obscure magic?
Margaret - Be careful about saying one DTL per UDP packet since UDP
packets can be fragmented, so you may end up with a single DTLS packet
per fragment. What happens when UDP needs to be fragmented? How does
this impact DTLS?
Janfred - The UDP fragmentation is independant of the DTLS records. For
RADIUS TCP we have the rule that there is a single
Alan - the DTLS record is independant of the outer UDP fragment. May be
multiple fragments but the application will only say "give me a full
record or nothing". DTLS application should take care of this
Margaret - Multiple layers of fragmentation? UDP fragmentation, then
also DTLS fragmentation?
Janfred - if there is fragmentation, the library will give you the whole
record, returing the whole thing or nothing.
Margaret - make sure to mention this
Fabian - DTLS spec says that a single record must fit in a single UDP
datagram, it could be fragmented - that's fine. DTLS record just cannot
span multiple UDP datagrams. Syslog metions that it can span multiple
TLS records. F. finds this is not a good solution. Recommends that one
RADIUS message must fit in a single DTLS record. If the library doesn't
provide for this, too bad. How to handle "garbled" packets. Because we
have protection, if we receive these, we should just close the
connection becasue clearly there is a problem with the source.
Heikki - Thinking that RADIUS UDP, when you create a UDP datagram, when
looking at we add padding. With DTLS do we do the same thing? If read 2
thousand from a socket, is there consideration if there is padding? Or
do with look at them?
Alan - Answer: we would have to root through OpenSSL implementation to
see what it does since this is not discussed very well elsewhere.
Heikki - When server has two RADIUS messages to send over a link, can it
put them together and send it over a link?
Alan - would be ok with that. Should be allowed in (D)TLS. Should check
if it is already done or allowed in (D)TLS.
Janfred - then would have the option to say that each DTLS record is a
single RADIUS packet, and then put multiple DTLS records in a packet.
Then you could ask the implementation to get you an entire record, not
just everything from a packet.
Alan - Other TLS implementations are running into the same problem. A
new doc could be nice. Eric Vyncke suggests that Alan should write this
document in the UTA WG, as many WGs / applications have run into these
issues.
Alex - while looking through OpenSSL docs and TSL docs - the reading is
straight forward: you will never get more than one record. Firm up that
you must write your RADIUS packet all in one go. Earlier drafts are
vague about this. One write should map to one record.
Fabian - Getting UDP fragmented up to the maximum TLS record length,
otherwise there is no check or complaint from OpenSSL.
Margaret - This was mentioned a while back. It would be great if
somehone where to write about options on how to do this (Alan).
Next Steps:
Fix remaining TODO's in the doc.
What else is needed for WGLC?
Janfred - We need to make sure we understand all of these changes, and
that they are implemented
Margaret - We shouldn't wait for the next IETF as the next revision
cycle. Should we have another interim meeting?
Janfred - Yes, this is a good idea.
(7 - 8 people in the room agree with this)
Margaret - Lets plan to do this in the Feburary-ish timeframe
### A syntax for the RADIUS Connect-Info attribute used in Wi-Fi
networks (Mark, 10 min)
draft-grayson-connectinfo
Connect-Info is in RFC 2859.
Motivation:
How best to share access network metrics:
Vendors have expressed interest in this. There are implementations in
CONNECT in various 802.1X
Relevant key value pairs for these metrics are outlined on the slides.
Sharing metrics where metric calculation can be customized.
Draft is an ABNF syntax and example encodings.
Next steps:
Heikki - It is good when things are clarified, this is good. Have you
looked that the incoming packets have the same CONNECT info or if this
changes for implementations.
Mark - we have seen a variety of deployments with diferent behaviour
Margaret - Was there a draft of this submitted to the WBA? How did this
end here?
Mark - because of timing, this approach was not taken (submitting a
draft to the WBA first). This has been discussed with the WBA though
with regards to brining this to this IETF (Dublin 121)
Margaret - Not trying to block discussion. We would need to have some
more discussion on this with the WBA. Will talk with the AD and the
document authors. Will take offline
Geatan - Reason for having all this info?
Mark - We have refered to RFC 2869 regarding this.
Geatan. - How would this be used? We are defining a syntax, we should
clarify the purpose of this.
Mark - Experience. Implementors can use this to improve their
implementation.
Karri - Quetion about this: Do you have any ideas how this would feed in
to the CONNECT octet length.
Mark - all of the examples are within the octet length max.
Margaret - there are known issue with the accounting metrics. Have you
considered these?
Mark - No. Will look into more.
### RADIUS attributes for NS/EP (National Security and Emergency
Preparedness Service) services (Sri, 15 min)
Mission critical services over:
NS/EP Priority Services:
In the US:
Other Countries:
Over Wi-Fi:
What are the gaps? What do we need in the RADIUS infrastructure?
Traffic Prioritization
EPCS functional flow with Authorization Control
Proposed attributes:
Capability Indication
Subscription Info
Additional Considerations: