RADEX WG Meeting, IETF 70

Minutes: Charles Clancy & Mauricio Sanchez

Agenda (Bernard)

Document Status (Bernard)

Published as RFC 5080: Issues & Fixes.

AUTH 48: RFC 4590bis has an issue with the Digest calculations in Appendix A.

RFC Editor Queue: RFC 3576bis has been approved for publication.

IETF Last Call Completed: New version of RADIUS location document posted.

RADEXT WG Last Call: Filtering and Redirection document completed WG last call during the summer. No comments. Will rerun WG last call.

Design Guidelines and Management Authorization documents have completed WG last call.  Both will probably need an additional WG last call.

RADEXT Work Items: Will discuss Attribute Extension draft today. This ust became a WG work item (-00).

Presentation: Design Guidelines (Bernard channeling Alan)

·         Guidelines for designing RADIUS attributes

·         Discusses RADIUS data model (existing types), limitations of complex types (only for security), polymorphic attributes (bad idea), grouping (use extended types, not RFC 2868 tag scheme).

·         Appendix A: type discussion, vendor-specific formats, new functionality

·         Appendix B: existing attributes vice design criteria

·         Discussion

o        Bernard: how many have read it? (3 responses for -01, none for -02), finished one WGLC, maybe do another?

o        Alan [jabber]: 02 had minor changes over 01

o        Dave [jabber]: has read 02

o        Bernard: people should read the document!

Presentation: NAS Management (Bernard channeling Dave)

·         WGLC completed, many issues resolved in -01, more to be discussed/resolved in -02 (revolve around management)

·         Publish -02, confirm to list, second WGLC to follow.

·         Discussion

o        Bernard: how many read the document? (3 responses)

Presentation: IEEE 802 Attributes (Bernard)

·         Started off about 802.11, but scope was broadened to include wired networks (IEEE 802.1af).  Review by IEEE 802.11 has been completed.

·         Next steps: WG review requested

Presentation: Crypto Agility Requirements (Bernard channeling Dave)

·         Goal: backward-compatible, interoperable mechanisms for negotiation of cryptographic algorithms within RADIUS

·         Current road block: IESG clarifying possible 4107/Automatic Key Management (AKM) issues

o        Dan R: where are we in the chairs’ opinion?

o        Bernard: need to know from IESG about whether Automated Key Management is a requirement or not.  It is not in the current set of requirements agreed to by the WG.

o        Dan R: who needs to provide answer

o        Bernard: Sam Hartman, discussion hasn’t yielded an answer so far; WG has been blocked since IETF 69.

o        Dave [jabber]: Thought that the Automated Key Management requirementdid apply based on list conversation

o        Alan [jabber]: Automated Key management is addressed by DTLS.

o        Stefan [jabber]: and RADSEC as well.

o        Bernard: does WG agree with adding Automated Key Management as a requirement?

o        Dan H: doesn’t agree that 4107 requires Automated Key Management.  This is only required if O(n^2) keys

o        Dan/Bernard: This doesn’t seem to apply to most RADIUS deployments. 

o        Joe: not clear if Sam was responding to need for crypto-agility in general vs need for AKM

o        Dave [jabber]: emails attached to slide deck

o        Bernard: (reads email from Sam from list)

o        Leif: should ask implementers, that’s what Sam was talking about

o        Steve H: Sam asking if we’ve heard from customers that radius key management is a problem, and if so then AKM may be necessary

o        Bernard: so it’s just up to WG consensus?

o        Bernard: (more email from Sam from list)

o        Joe: This is not a FIPS issue; for FIPS certification, requirements only on crypto modules

o        Steve H: anyone here from EduRoam to discuss AKM?

o        Stig: deployed EduRoam, AKM might be nice, but coping with radsec/TLS

o        Alan [jabber]: AKM for RADIUS is not a problem

o        Stefan [jabber]: AKM not flexible enough for roaming

·         Back to requirements slides (5/5): is this consensus of WG, and would this result in a DISCUSS?

o        Lakshminath: 4107 says they’re guidelines and WG needs informed consensus, documentation of choices in security considerations

o        Dan R: One way of moving forward is to write text for security requirements section, run by Sam Hartman, see if he would support it or block it during IESG review

o        Stig: not clear what AKM really is, in EduRoam there is static peering so it’s not a problem

o        Bernard: determine if consensus of WG is that AKM is necessary

o        Bernard: hum if you don’t believe AKM should be required (some, jabber hum from Dave)

o        Bernard: hum if you DO want AKM (room silence, jabber hum from Stefan)

o        Bernard: WG consensus that we don’t want to require AKM, need to write up text as to why 4107 doesn’t require it and we don’t want it

Presentation: RADIUS + DTLS (Bernard channeling Alan DeKok)

·         DTLS (RFC 4347), openssl implementation, other WGs using it, would solve all requirements

·         Can run on same port as RADIUS with ability to demultiplex DTLS and normal RADIUS sessions.  Therefore, no IANA considerations, DTLS orthogonal to RADIUS security (both can be run at the same time).

·         RADIUS + DTLS is a transport layer change, not a protocol change, therefore no Diameter impact

·         Discussion: no changes from -00, feedback positive

o        Bernard: has this been implemented?

o        Alan [jabber]: someone from Avaya has implemented it, but he has not

Presentation: RADIUS attributes for crypto agility (Joe Salowey)

·         Approach: rather than use a transport layer encryption, reuse keywrap/encattr, working on combined draft, does not provide AKM but it could be developed

·         Some implementation for a similar scheme

·         Advantages: coexist between legacy and new, transport remains the same, could support multi-hop security

·         RFC4107: requirements don’t seem to apply

·         Discussion

o        Bernard: so new draft coming soon? Not a winner takes all, so both could be adopted

o        Joe: Yes. Update to take advantage of extended attribute format.

Presentation: RADSEC (Stig Venaas channeling Stefan Winter)

·         Implementations: Radiator implementation (radsec proxy), FreeRadius implementation being considered by Alan, LANCOM systems has alpha release for Radius client

·         Interop tests: radsecproxy <-> radiator, LANCOM -> radiator, LANCOM -> radsecproxy

o        Stefan [jabber]: on routers regarding LANCOM, can be used to access 1X networks

·         I-D updates: include shared-key support, remove EduRoam appendix, certrequest issues

o        Bernard: TLS exchange then use the CA DN to guess right consortium.  SRV RRs used to find the RADIUS server for a given realm?

o        Stig: manual configuration, static peering today; no use of SRV RRs.

o        Bernard: question about radsecproxy, can go on an AP or in front of a RADIUS server?

o        Stig: tested with AP running linux, install radsecproxy, same on the server side, being used in EduRoam for routing.  Enables use of RADSEC on NASes, proxies and servers.

o        Bernard: radsecproxy doesn’t involve SRV lookup?

o        Stig: not yet, working on it

o        Bernard: deployed today in EduRoam?

o        Stig: yes, in production but on a limited scale

o        Stefan [jabber]: radsecproxy can replace proxy-only servers completely

o        Dan R: what does the WG want to do with this?

o        Bernard: what do the authors want the WG to do with this?  Not part of the current charter.

o        Dan R: Prague consensus was that it doesn’t belong in the charter, does the WG want to recharter, has anything changed since Prague?

o        Stig: think it’s a good solution, might be other solutions, something that works well for EduRoam, wants to see it go forward in some way

o        Bernard: immediate way forward, document certificate stuff, refine draft to reflect ongoing deployment

o        Stig: at the very least, it would be nice to document what is done

o        Alan [jabber]: I think radsec is acceptable as a WG item, many people use IPsec+radius and RADSEC and TLS/DTLS is easier

o        Stefan [jabber]: IPsec radius is a pain, knows people who have deployed it, since it is now implemented on a number of NASes such as Aruba, and most operating systems support it.

o        Dave [jabber]: didn’t we restrict RADSEC to proxy uses and not end users?

o        Bernard: Draft mentions that as typical transition strategy, but it is not a restriction.

o        Leif: another aspect of tunneling over IPsec, no channel bindings, not same level of security as running over TLS.

o        Bernard:  RADIUS is not cryptographically bound to (D)TLS channel either, correct?

o        Bernard: wrt to proxy, had to work with existing radius clients, if proxy can be on the NAS… does it work with regular radius?

o        Stig: NAS can still do normal radius

o        Stefan [jabber]: doesn’t remember that (response to Dave)

o        Dave [jabber]: yeah, IPsec not ideal solution (response to Stefan)

o        Dave [jabber]: roaming consortium dictates use of proxies?  Yes.

o        Alan [jabber]: TCP slowstart issues with RADSEC?

o        Bernard: In RADSEC, client will operate in perpetual slow start if TCP parameter decay is implemented as described in RFC 3539, since volume of traffic is low.   There may also be an issue with delayed ACKs if initial window size is 1.

o        Stig: thinks slow start might be an issue, in radsecproxy use keep alives to keep TCP sessions open

o        Bernard:  RFC 3539 describes decay of TCP parameters, such as window size.  This only matters if you’re sending a burst of traffic, want initial window size of 2 rather than 1 to avoid delayed ACK; implementers can look at TCP traces

o        Alan [jabber]: stateless server for radius draft may be expired

o        Stig: isn’t that Alan’s draft? Hopefully he’s going to renew it?

o        Bernard: documentation of existing usage, not a new thing

o        Dan R [AD hat on]: feeling is that there is not WG consensus to recharter to include radsec, if we are entertaining such a discussion need to consider how this changes AAA IETF environment, not a simple discussion; on the other hand believe that we do have a consistent piece of work with running implementation and deployment, so it’s not to be ignored or put aside; between now and next IETF cycle, determine if this work has enough traction to recharter RADEX, or do BoF in Philly; authors could also do an individual submission, but hesitant to recommend that course of action because we do have a WG in the IETF working on RADIUS and parallel activity doesn’t seem proper thing to do

o        Bernard: limitation to recharter is finishing enough of the current charter to make that seem like a reasonable thing to do; some things in WGLC

Presentation: RADIUS support for EAP Re-authentication (Lakshminath Dondeti)

·         Using slides from IETF 69 that were never presented due to running out of time.

·         Original draft used new RADIUS attributes for key request and key response; new draft reuses EAP-Message Attribute.

·         Need a mechanism to deliver keys securely (e.g. RADIUS keywrap or transmission layer security).  Can RADEXT make progress on that?

·         ERX document represents an update to RFC 3579, similar document for Diameter

o        Dave [jabber]: can it work with other RADIUS crypto agility solutions?

o        Lakshminath: yes

·         Next steps: need RADIUS considerations and diameter considerations for HOKEY, need a solution to the key protection problem

o        Dave [jabber]: talk to Sam Hartman about 4107 applicability

o        Charles: worried about O(n^2) for HOKEY

o        Bernard: Why would HOKEY be different than normal RADIUS key management in that respect?  Wouldn’t it just be O(2n)?

o        Dan H: worried that the proposal turns RADIUS into a 3-party protocol. 

o        Bernard:  That may be an issue, but it doesn’t affect keywrap, that is still hop-by-hop.

o        Steve H: thinks it’s O(n) between NAS and AAA, but O(n^2) between AAA and AAA.

o        Bernard:  Does HOKEY require synchronization of key state between AAA servers?  Didn’t see that in the document.

o        Charles: RFC 4962 requires O(n^2) and that then requires AKM

o        Glen: RFC 4962 doesn’t require you to not expose keys to proxies.  Therefore it’s still O(n).

o        Steve Hanna: might be a good case for AKM

o        Glen: wonderful idea, roaming networks have been passing keys through proxies for 5 years – definitely need to destroy those networks

o        Steve Hanna: things that have been around for 10 years doesn’t necessarily make them secure

o        Bernard:  If the desire is not to expose keys to proxies, then there are solutions available to avoid that (e.g. Diameter Re-direct, SRV RRs + certificate hierarchies with TLS, etc.). 

o        Bernard: next step, revise the draft and ask RADEX for review

Presentation: extended attributes (Glen)

·         No slides, discussion:

o        Glen: How many have read it (4 responses)

o        Glen: extended attribute looks like old-fashioned VSA, extends attribute space using a Vendor Code of zero for IETF.

o        Glen: seems to work pretty well, however TLVs have exactly the same format as traditional radius attributes; not possible to group legacy attributes, would like to add a flag to the TLV header to say whether or not this is a legacy attribute so you can include old-fashioned attributes in new-fangled attributes without type-space conflict

o        Dan R: define legacy

o        Glen: any previously-defined attribute

o        Bernard:  Would this support grouping for both existing and new attributes?  Wouldn’t this change the semantics of existing attributes?

o        Dan R: When this is adopted – do we freeze allocations in the existing attribute space?

o        Glen: no, people can still define attributes in the older space or they can ask for allocation in the new space to take advantage of new capabilities (e.g. grouping, larger attributes).

o        Bernard: any pending issues in -00?

o        Glen: No Diameter considerations yet.  This has to be added.

o        Dave [jabber]: TLV header, does it mean the base radius message or just in the header of the extended atribute?

o        Alan [jabber]: why not use the same layout?  We want to avoid multiple similar approaches.

o        Dave [jabber]:  We should either go with the WiMAX VSA approach, or not.

o        Glen: The extension draft was co-authored by the WiMAX forum security co-chair, so the extension draft is backward compatible with WiMAX VSAs.  However,  change is a positive thing, we want way to group standard attributes as well .

Open Discussion:

·         Steve Hanna: Should we revisit discussion of AKM, customer demand for AKM In light of new discussion about roaming/proxy issues in HOKEY?

·         Bernard: The Security ADs will probably want  to protect the keys

·         Steve H: The Security ADs will probably need AKM, no?

·         Bernard: is AKM really a requirement for crypto-agility? We have proposals that do security in different layers – DTLS/RADSEC (transmission layer) and RADIUS crypto-agility (application layer).  They can be used individually or in combination.  

·         Steve Hanna: will any proposal get to RFC status w/o AKM? Put two forward, one with AKM and one without, and let the Security ADs decide?

·         Bernard:  Current proposal is to publish both approaches as Experimental, and let the market decide.  Security ADs have not said they will impose solutions on the WG against WG  consensus.  They have just asked for justification.  

·         Lakshminath: I’m confused about O(n^2).  Wrt proxies and 4107, analyze threat model – what might proxies do if they have the keys?  Attacks at the edge more likely/meaningful, why would a proxy want to attack the network?  Approach might be to do threat analysis

·         Bernard: RFC 2607 had a threat analysis.  The most serious threats related to accounting attacks by authorized parties (dishonest local networks stealing from home networks).  Stealing keys is typically less interesting than stealing money.  

·         Lakshminath: What’s the end goal, stealing money?  

·         Glen: unaware of any roaming network that has O(n^2) pairwise security associations because key provisioning is too difficult, which is why proxies exist; if we say “get rid of proxies and install a full mesh” we will be laughed at; unaware of anything that’s completely secure, using it in a black and white way; is it secure ENOUGH for our purposes?

·         Steve Hanna: agree with real-world security discussion, not suggesting that we obsolete RADIUS proxies

·         Leif: Can we allow several proposals to move forward?

·         Bernard: yes, that is the proposal.

·         Leif: at least one of them would support AKM via PKI?

·         Bernard: Yes.  As long as we’re in agreement, then we can bring this to the list for verification.

·         Bernard: hum if you feel AKM is not a requirement (some)

·         Bernard: hum if you feel AKM should be a requirement (none in room)

·         Bernard: same as before.  WG consensus is that AKM should not be a requirement.

Meeting Adjourned.