********************************************************************************* 1. RADIUS Extensions for IP Port Configuration and Reporting, Dean Cheng draft-ietf-radext-ip-port-radius-ext-01 - presented per slide deck - First draft presented at IETF89 - No significant changes to outer TLVs - New Sub-TLVs added from discussions on mailing list - Clarification of when Sub-TLVs are optional/required depending on parent TLV. - IANA numbers requested in extended namespace for TLVs - Stefan: Protocols such as TCP, UDP, ICMP are enumerated, what about SCTP and others, too exotic? - Jouni: Can't SCTP run over UDP, could it be represented that way? - Arran: Maybe? - No consensus on protocol enumeration, further discussion required. - Arran: Is there support for reporting on PCP invoked mappings? - Dean: No not currently. - Discussion to continue on mailing list. - Next steps - More comments are reviews from working group. 2. Support of fragmentation of RADIUS packets, Diego Lopez draft-ietf-radext-radius-fragmentation-07 - presented per slide deck - Stefan raised 6 issues since 06 but all have been (will be addressed) in 07 before TSVDIR - Status hopefully moved to "Waiting for TSVDIR review" - Alan: Can't do fragmentation across internet with CoA because 5176 doesn't support proxies. - Diego: Will note this in the document. - Alan: Known issue being worked on. - Section 6 not clear about fragmentation limits in both total size limit and packet count. - Diego: New section clarifies specification use, does not interact with transport layer. - Next steps - Minimal issues to resolve (Stefan will hopefully, remotely smile) 3. Dynamic Authorization Proxying in Remote Authorization Dial-In User Service Protocol (RADIUS), Alan DeKok draft-dekok-radext-coa-proxy-00 - presented per slide deck - This has been progressing for the past two years with Jouni as Co-Author - Describes how to use CoA proxying in a Roaming environment, RFC 5176 says you can, but doesn't define how. - Solution to add Operator-Name and Operator-NAS-Identifier attribute to specify path to home server. - Operator-Name now in use by Eduroam - Implemented today in FreeRADIUS - Sam (via Jim): Include discussion about security considerations, traceability, reusing same Operator-NAS-Identifier with multiple sessions. - Alan: Given current state of security in RADIUS (mostly cleartext) probably not an issue. 4. Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) draft-dekok-radext-datatypes-02 - presented per slide deck - Fix long standing issue in RADIUS - Past ~22 years RADIUS has used TLVs from dictionaries, but none define data types. - RFC2865 defined some but most others haven't. Has lead to conflicts. - What do we do? Add an IANA registry for data types, and an RFC to define them. - Next steps - Accept as WG document, publish as standards track, start using data types in new specifications - Benoit: Do we only apply data types from now on, for new RFCs/attributes? - Alan: Most attributes already defined without conflict (except maybe RFC 3162). - Alan: Vendors have already created data types for IPv6, this formalises that. - Alan: Not many uses for brand new data types. - Alan: This document defines types for all existing attribues. - Dean: Can we reference existing RFCs (2865 et al) for data types? - Alan: Sure, but there's no registry. Better just to push this document quickly. New documents should reference this draft. - Dean: For integer types should a size be specified? - Alan: No there are two types 'integer' (32bits) and 'integer64' (64bits) no point in defining smaller integers, as gains are minimal. 5. Considerations regarding the correct use of EAP-Response/Identity draft-winter-radext-populating-eapidentity-00 - presented per slide deck - Seeks to solve issues with encoding non UTF8 identities, and identity selection. - Draft still doesn't have a home, hopefully adopted by radext? - Alan: invalid radius packet? which technically correct no one actually cares about what's in the username? - Stefan: - Alan: What about 802.11u it advertises available realms? - Stefan: 802.11u doesn't solve the problem, too many realms to encode in eduroam. - Stefan: AP can also just send 'I am member of consortium X' instead, which doesn't help here. - Other draft RFC 3579 (EAP/RADIUS) uses Calling-Station-ID when no User-Name available. Has this been considered? - Stefan: Not considered, will read RFC, appreciate comments. Documents to be adopted by working group - Jouni: Three new documents (coa-proxy, datatypes, eapidentity) what's the consensus for adoption? - Alan: Unsurprisingly supports adoption of his drafts (coa-proxy, datatypes). - Jim: eapidentity - advisory at best, probably doesn't make sense at this moment. - Jim: Doesn't care about coa-proxy. But datatypes should have been done years ago, Sam/Jim will review. - Lionel: Fine with coa-proxy and datatypes. - Benoit: Is existing charter sufficient for the the new documents (coa-proxy, datatypes)? Or recharter necessary? - Jouni: Will try to find justification to move forward under existing charter. Interest in implementing Coa Proxy - Alan/Benoit: Anyone else interested in implementing CoA proxy? Would be good to have another implementation? - Room: Not really... - Alan: Operator-Name in widespread use today. - Alan: CoA-Proxying is a major issue, so it should still move forward. Discussion around moving documents to the standards track - Jim: Proposes moving TLS (RFC6614) from experimental to the standards track. - Alan: Agrees. TLS in widespread use. Should republish with no changes. DTLS can probably wait for now. - Alan: Accounting (RFC 2866) is still informational, should that be republished too? - Alan: Does experimental/informational status cause any real problems? - Jim: Issue with experimental is if it has dependencies (like ABFAB has for TLS) it's harder to progress it, informational easier. - Benoit: Probably not much point for accounting.