docs: - larger packets in auth 48 - IP port in publication requested - data types in RADIUS - AD review - updates pushed out before the meeting, pretty much ready for IETF last call drafts: - CoA proxy completed WG last call - chance for WG members to do last review - considerations regarding correct use of EAP-response identity, discussion in this meeting new work - tis-bis - LoWaWAN - MPTCP - extended packet header - Alan makes a comment that we may have a new proxy considerations / best practices document CoA proxy document - barring comments from Peter Deacon, the document looks to be good Q from Stefan: what if the reverse (CoA) path is not a mirror of the forward (auth) path? A from Alan: no idea. Someone using that architecture should write a draft proposing what to do We assume that the CoA / RADIUS proxies are tightly coupled, and there's a 1-1 mapping between the two EAP identity doc (slide summary) text on identity selection hints can likely go away - WiFi passpoint / hotspot 2.0 has 2 profiles configured authenticator has to decide which one to use - but if SSID allows both credentials, which one to use? - new rev soon with ASCII art.. Q from Alan: who is aware of this and implementing it? A: major vendors implement passport already, OS vendors indicate support for passpoint. implementations vary in quality. Lionel: would it simpler to assume that the identity is relevant enough to figure out which realm to address? diameter has the same issue... Stefan: doc says it's up to local config for how to split user/realm identifier. Lionel: thats' good enough Jim Schaad: having issue with "Converge on open issue" in slides. What are the options for the solution? UI? nothing seems to have good recommendations Stefan: not something that needs fixing in a UI. the problem is more with the EAP state machine. If you have more than one realm identifier, you have to re-start the EAP state machine after you've failed with one credential. probably just back-end code in supplicants, with minimal UI / config changes. Maybe just allow people to manually order EAP types. the state Brian Ness Cisco - confused on privacy situation... "when privacy is important", now privacy is important. will client device use all credentials both times? Stefan: clients will use only the credentials that they know will work. Brian: Suggest making the privacy section stronger. maybe not protected against an active attack? Stefan: many EAP types in use today, privacy extensions work. e.g. EAP-PWD doesn't have that option. draft says to try those types last. RFC6614bis - realized there were open issues with the document, and issues where it wasn't clear which document should address it - need to decide if use of tickets is SHOULD or MUST - issues related to transport layers - TLS option questions - issues related to I can use the right cert, but do I trust the entity associated with the cert? - DNS lookups likely not in this document - not clear whether we need to document (or not) DANE, as it doesn't really solve the problem - what should be in a certificate that is used for RADIUS? - define extended key usage for RADEXT if not already done - TLS tickets in 1.3 become very useful, reducing reconnect time for setting up a second channel - potentially a huge win. - application data can be sent along with PSK in first message - need to rev TCP to standards track Alan: I think many people use DTLS in internal networks, between APs and controllers Stefan: Which implementation do they use? Alan: radsecproy - issues related to TCP / UDP and UDP / TCP proxying and retransmits - who retransmits? - issues related to large packets, too. LoRaWAN draft - motivation of the draft is to include AAA into LoRaWAN - AAA is scalable - overview of LoRaWAN join procedue - keys transported similar to RFC 6218 (Cisco key transport) - open issues need to map AppEUI to realm - match AppEUI to domain name of organization - maybe use inverse of RFC 7043? - proof of concept implementation discussion around encapsulation of LoRaWAN protocol as-is inside of RADIUS, or broken out via RADIUS attributes - if RADIUS needs to look at the encapsulated data, probably RADIuS. Lionel: what is expectation related to where this work is done? Dan Garcia (jabber): agrees with Alan's comments re: one attribute, and processing the LoRaWAN data as-is Lionel: Questions related to location of AAA server... - some comments on IETF process... we can do the doc here or elsewhere, depending... - this doc promotes the use of AAA infrastructure Stefan: is lack of RADIUS standardization holding you back? A: it would help, as of now, the join server doesn't exist MPTCP RADIUS - no slides - no change from the slides or draft, stable, adheres to recommendation from WG Stefan: is it being used? Med: MPTCP is experimental. use-case involves CPE and another MPTCP proxy. these two entities are not standard. - goal is to increased experience of customer, and for service provider to support new things... (?) - multiple access networks need to be correlated in order to provide better services to customers - many deployments exist - implementations are not standardized, but proprietary Lionel: get interest in the mailing list Med: want to avoid defining something bad WRT RADIUS Alan: could be individual draft Lionel: Yes, we need to decide what to do Extended Packet Header for RADIUS - Enke Chen from Cisco - 8 bit identifier is bad, need to extend it. - 100K+ sessions in some apps - results in issues with local ports, TCP usage, efficiency, etc. - capability discovery via Status-Server Stefan: this is a major change for RADIUS Alan: at least one commercial RADIUS server uses a VSA to do this Lionel: if you need more than 256 IDs, just use Diameter. - RADEXT extends RADIUS Enke: it's a practical challenge we have Lionel: If we're saying that RADIUS isn't fine as a protocol, we might as well move to Diameter (?) Cisco - if we have such a use-case and the server side, if you don't support it, then you don't support it - the protocol needs to move forward, it's a real issue Enke: it's probably a few hundred lines of code changed. Stefan: we should go home and think about how best to solve the problem. Is it a small band-aid, or a large band-aid? we have to do something. Lionel: discuss on the mailing list.