radext 94 ------------------------------------------- 14:00 - 14:05, Preliminaries (5 minutes) Presenter: Lionel Morand Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-radext-0.pdf Note Takers: Ao Kobayashi, Jean Mahoney Jabber scribe: Jean Mahoney slide 1: Title slide 2: Note Well slide 3: Agenda 1/2 Lionel - Sam is not available to present the bigger-packets draft. slide 4: Agenda 2/2 ------------------------------------------- 14:05 - 14:10, WG Document Status (5 minutes) Presenter: Lionel Morand Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-radext-0.pdf * draft-ietf-radext-dynamic-discovery --> RFC 7585 * draft-ietf-radext-bigger-packets-04 --> Waiting for Write-Up (Experimental) * draft-ietf-radext-datatypes-01 --> In WG --> WGLC? * draft-ietf-radext-ip-port-radius-ext-06 --> Waiting for Write-Up (Standard) slide 5: WG Status Update (1/2) Lionel - bundling authors didn't request mtg time. Can be discussed on ML. slide 6: WG Status Update (2/2) Lionel - bigger-packets - WG consensus, waiting for Stephan's writeup. Almost ready for IESG submission. port-radius-ext - finish up writeup after this meeting. Need more reviews on datatypes. proxy doc - last meeting, it was decided that it would become an radext document, but never sent to the wg ML. There's a discussion with peter deacon, eapidentity - need to confirm on mailing. Jean Mahoney for Alan deKok in the Jabber Room - the COA document has expired, working on an update that should be out this week. slide 7: WG Status Update (2/2) slide 8: Errata on RFC 2866 Lionel - on going discussion with Stefan. Don't know if it's verified or to be reconsidered based on discussion. Jean for Stefan Winter - Verified is ok with me. slide 9: Milestones slide 10: WG Drafts Discussion slide 11: Individual Drafts Discussion ------------------------------------------- 14:10 - 14:20 RADIUS Data Types Presenter: Alan DeKok Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-radext-1.pdf Draft: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ slide 1: Title slide 2: Data Types slide 3: Discussion? Alan - There are 200 data types that need to be verified. Need to validate the data type is the correct on in the original RFC since some of the RFCs are silent or ambiguous on them. Lionel - the review can be done in a WGLC. We can split the data types - 20 to one, 20 to the other. ACTION: Data type validation to be split among reviewers, each taking on 20 or so. ------------------------------------------- 14:20 - 14:30 Bigger Packets, Sam/Stefan (10 minutes) draft: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Presenter: N/A Presentation: N/A Lionel - Sam can't make it. Jean for Stefan in the Jabber room - The main issue right now (raised by Alan) is the use of 2-octet integer vs. unsigned 32-bit integer as per data-types for the max fragment length. Even though datatypes is not an RFC yet, there seems to be broad consensus to re-use existing types, so a change towards unsigned 32-bit integer is probably the right thing? Alan - yes. RFC 6929 forbids the use of new non-standard integer types. There's no purpose for it to be 16 bits. That can be a restriction - if you see something over 16 bits, ignore and treat it as non-existent. I haven't seen feedback from Sam. Lionel - we can reach an agreement on the ML. Stefan will decide when the draft will be sent to AD review. ACTION: Reach agreement on the mailing list on using real integer for max fragment length. ------------------------------------------- 14:30 - 14:50 RFC3580/RFC2866 Issues and proposed fixes Presenter: Alan DeKok Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-radext-2.pdf slide 1: Title slide 2: Open Issues Alan - I added 4569 on MS-CHAP-MPPE-Keys, Benoit rejected it for many reasons. slide 3: MS-CHAP-MPPE-Keys slide 4: MS-CHAP-MPPE-Keys Alan - Do we want to address this as an errata so that the readers know how to implement properly or decide that most people have figured out what to do? Jim Schaad - It's my understanding that MS-CHAP is not considered secure. Alan - do we we want to explain how to implement or do we want people to run head long into a wall and fall down twitching? Jim - That latter might be the best answer in this case. slide 5: Acct-Session-ID Jean for Stefan - is MS-CHAP-MPPE-Keys always 24 octets? Alan - can be 8 octets of 0 followed by some stuff, making it problematic. slide 6: Acct-Session-ID slide 7: A Proposal slide 8: Discussion Linus Nordberg - a question - is it correct.... Alan - No, it's implied to be a token associated with user session. It's valid to send the same Acct-Session-Id for every user session. The intent is to require the NAS to create good values to uniquely identify the user session. Linus - are we adding something to make it unique? Alan - I would consider observers of network traffic as different from consumers of network traffic. If you are concerned about observers - use TLS, IPSec. The RADIUS security is bad enough there's no excuse for sending RADIUS packets in the clear. Linus - I agree about protecting the contents. But if we add a way to track a user across networks that wasn't there before, deployments would have to change to another protocol. Alan - I don't think we're creating anything new. It's just a bad idea for session identifiers to be the same for multiple sessions. Lionel - ... Alan - the key is that the session identifier has no meaning. You can send English words if you want. If they vaguely identify a session that's ok. They should more strongly identify a session. When a NAS creates one, it should use a better method. Nothing else should change. slide 9: Question Lionel - on backward compatibility issues, any NAS not complying will not be compliant with the RFC. The session needs to be globally unique. 3580 - when you use this, you may have additional requirement and you can add this. I don't think we need to update the RFC. There's no recommendation on how to have a globally unique session id. Maybe we can provide a recommendation. Alan - sound fine. Lionel - maybe have a draft, and not update RFC 2866. I'll double check 3580. If you have further constraints on the AVP... Alan - sounds ok. slide 10: Acct-Status-Type slide 11: Acct-Status-Type Lionel - The Designated expert is Bernard, who is waiting on the output of this discussion. I understand the clarification, but there's no notion of subsystem in RFC2866. Maybe put the info somewhere else? It's just relying on how the NAS is implemented. Alan - An issue that hasn't been addressed is the privacy of the visited network, the IP address of the NAS is out there. How do you signal upstream that part of network went down/up. You don't want to send 1000s of messages. You want to say some group of users was disconnected. If the NAS is a visited network or a wireless access point. You need to signal that a large subset of users has been kicked offline without kicking all of them off. What do we mean by subsystem, it's not defined. Lionel - need to discuss the impacts introducing the concept of the subsystem. You can even describe it as group of user A, group of user B. ACTION: Discuss the impacts of introducing the concept of a subsystem on the mailing list. Alan - looking at the current use of the acct-status-type. They're using it this way. If we define an acct-status-type, they won't be using it incorrectly any more. Intent is that - IANA say these values are to be defined by an expert, so we can do this. Use this rather than accounting-off accounting-on. Lionel - If we agree on the value of subsystem-off, subsystem-on, need to document to clarify how to use the information and the behavior of the server receiving the info. Talk on the ML. What existing issues will be fixed with this. Alan - I posted a writeup to the ML and on FreeRADIUS web page. We don't need IETF consensus, but it needs to be documented by someone somewhere. It covers how people are using it right now. Issuing an RFC is not the right thing to do, unless we cover 15-20 changes in the doc. Lionel - We can discuss further. Defining new values without knowing how to use them, not so useful. I'm not saying a new RFC. Want to make sure that defining new value solves the problem. What's the trigger to implement this new value? Alan - it's clear that the vendors aren't using accounting-on, accounting-off correctly. They don't show up at IETF. They just do something that seems to work. I've talked to different vendors and people using different implementations, I've documented on the webpage how people are using it. Lionel - have discussion on the ML. Need feedback from Bernard and others. I understand what you are saying. I'll try to clarify my point on the list. ACTION: Discuss on the ML clarifying how to use subsystem-off/subsystem-on and server behavior upon receiving the information. Identify the existing issues that will be fixed with subsystem-off/subsystem-on. slide 12: Conclusions slide 13: Conclusions (2) Alan - Bernard's feedback - any changes to 3580 require feedback from IEEE. Section 5.4 says when used with IEEE 802.1x authenticators, the Account-Session-ID SHOULD be unique. I prefer that it say MUST, not just for 3580 and IEEE networks but all networks and text on how to create a Account-Session-ID. I don't think Account-Status-Type requires IEEE feedback. Lionel - need feedback from IEEE to update the document. Dorothy Stanley, HP - what feedback do you need? Alan - Want to pass suggested text through IEEE to see if it will break anything, or it's fine. Doesn't need official documents, just that IEEE has reviewed and is ok with them. Dorothy - let me know when the updates are available. Alan - updates are not available yet. Lionel - The contents of this RFC comes from IEEE, changes need to be endorsed by IEEE. It's the first client of the spec. Dorothy - 3580 is general, not just IEEE. Lionel - it's informational RFC and covers how to use in IEEE network. Dorothy - I'm happy to take an updated doc to .11 and get feedback. Contact me when the document is ready. Lionel - we'll discuss on ML. I don't know what the document will be. Could be an RFC update or a draft. ACTION: Propose Account-Session-ID text on the mailing list. Dorothy Stanley to solicit IEEE feedback. slide 14: Discussion? Lionel - need more reviews. ------------------------------------------- 13:55 - 14:00 Next Steps: WG Chairs & ADs (5 minutes) Presenter: Lionel Morand Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-radext-0.pdf slide 12: Next Step Lionel - Need more reviewers for WG docs.