Minutes for RADEXT at IETF-96
minutes-96-radext-3

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.