---------------------- RADIUS Extensions (RADEXT) Minutes IETF-68 Prague, Czech Republic Wednesday, March 21, 2007 9 - 11:30 AM -------------------------------- Chairs: Bernard Aboba, David Nelson Note Takers: Mauricio Sanchez, Alan DeKok -------------------------------- Agenda -------------------------------- Blue Sheets Note Takers Jabber Scribe Agenda Bashing Document Status Documents in WG Last Call RFC 4590bis RFC 3576bis Issues & Fixes WG Work Items NAS-Traffic-Rule Attributes Pre-WG Review WLAN Attributes RADIUS Design Guidelines RADIUS Crypto-Agility RADEXT Crypto-Agility Requirements RADIUS + DTLS RADIUS Crypto-Agility RADIUS Pre-Paid Document Status =============== Two documents are in the RFC Editor Queue: Delegated-IPv6-Prefix and the RADIUS Filter-Rule document. Three documents are in WG Last call: RFC 4590bis, RFC 3576bis, and Issues & Fixes. Bernard: Draft-lior-radius-attribute-type-extension-01.txt is in pre-WG work item review. No one responded to the original call for review in December, so we have issued another call. So far noone has reponded to that one call. Glen Zorn: I have read it. I love it. Alan DeKok: I have read it and will post comments. Bernard: This is a very short document. People in the room can easily read it during this meeting. Please do! RFC 4590bis (Wolfgang Beck) =========== This document came out of errata discovered in RFC 4590. These were serious enough that submitting errata to the RFC Editor was not considered sufficient. For example, there was a problem with the IANA allocation of RADIUS attribute numbers. Issue 196: Addressed Issue 205: IANA error (fixeda) Issue 206: Digest-Method optional, State attribute usage not clear (fixed) Issue 218: Inclusion of existing attributes to put in accounting records Wolfgang: Are we fixing the document or adding features? Bernard: We are not adding attributes, just specifying whether they can be included in accounting packets or not. Bernard: which existing attributes should be allowed in accounting records? Current attribute table reviewed: Wolfgang: most make sense. Needs additional time for review. Bernard: Please review the document so that we can get this out. RFC 3576bis (Bernard Aboba) =========================== Issue 212: Review Terminology - RFC 3576 uses different terms than the RFC 3576 MIBs. Should we change the terminology? It is easiest to leave this alone unless there is an interest in changing it. Does anyone care? No answers -- leave it alone. Issue 215: Authorize-Only in Disconnect-Request Avi has filed an issue to remove this. The claims of Diameter compatibility in RFC 3576 are wrong -- use of Authorize-Only in a Disconnect-Request actually is a cause of interoperability problems, not a solution. Any objections to removing this? No. Issue 223: Event-Timestamp Event-Timestamp looks difficult to use; currently it is suggested for replay protection but the document says that it is updated on retransmission, which interferes with duplicate detection. RFC 2869 Section 3 prohibits Event-Timestamp except in Accounting-Request. Alan DeKok: Event-Timestamp is the time of the original transmission, no? If so, RFC 3576 is wrong. David Nelson: I think it was the time of the event. Bernard: The proposed resolution is to suggest that Event-Timestamp not be changed on retransmission. Has anyone implemented this? Noone speaks up. Nonce Attribute Since Event-Timestamp requires time synchronization, the Nonce attribute was added. Steve Hanna: Time synchronization isn't really necessary -- just monotonicity. What if the recipient cannot handle the Nonce attribute in a CoA/Disconnect-Request? They will respond with a CoA/Disconnect-NAK and an Error-Cause attribute with a value of "Unsupported Attribute" -- but no indication of which attribute is at fault. Also, the current nonce is 32-bits, it would need to be 128 bits or larger. Joe Salowey: Does the Nonce attribute really address the same issue as Event-Timestamp? It provides "liveness" -- but does it handle replay? Implementations won't remember the nonce from 3 days ago. Bernard: Good point. I think we should remove the Nonce attribute, and leave Event-Timestamp in, and clarify that Event-Timestamp is the time of the original event so that retransmissions don't change it. RADIUS-Diameter error message translation Error message mapping is included in the document. Can people look this over? Issues & Fixes (Alan DeKok) ============== Reviewed comments since last call alan: The duplicate detection mechanism now in the spec has been implemented. Session should be tracked via the State attribute to provided a per-session EAP identifier. This is also implemented. Are we done yet? This spec has been kicking around for years. Time to ship! Bernard has question on per-session EAP identifier usage for duplicate detection. Concerned that when enabled it may introduce EAP identifier limitations. Alan commented that RADIUS implementations require a session tracking layer on top anyway. Extended Filter Attribute (Mauricio Sanchez) ========================= Mauricio: Draft -02 has finally been published. There are three big changes: removed ordering requirements, rule versioning, diameter considerations redone. Bernard: Is there version negotiation? Mauricio: No. Capablity / version negotiation is for the future. Mauricio: 9 issues remain open. Some have been open for years. We need people to review the resolutions in order to obtain closure. Bernard: Maurico will post proposed resolutions. If no comments, we will close the issue. Issue 130: Diameter considerations. Here we will follow the RFC 4675 approach. There is an open question on the value type. Bernard: what did we use for Filter-Rule (Looking it up) Alan DeKok: Is the Diameter IP-Filter-Rule type better suited? Mauricio: We will resolve issues, post -03 and then bring it to WG last call. We will then revisit the need for radext-redirection Hannes: some DIME participants thought that the document is not yet what they would need, but don't have details. Hannes: will solicit comments in DIME tomorrow. Mauricio: What are there concerns? Hannes: version is separate issue... match part && action part to do specific behavior. That part needs extensibility, too. Don't want to change format and version when you add an action. Bernard: RADIUS Filter-Rule document doesn't have a large Diameter compatibility section, because it was taken from Diameter. WLAN Attributes (Bernard Aboba) =============== IEEE 802.11 has submitted their review of this document. There are questions about whether whether a separate SSID attribute is needed, and why Allowed-SSID/Allowed-Called-Station-Id can't be combined into a single attribute, using the same format as Called-Station-Id (e.g. MAC Address + SSID). Also, there have been questions about whether the more granular 802.11 authorizations are needed (e.g. to distinguish an IEEE 802.11s EAP authentication used for "Mesh Join" from an IEEE 802.11i authentication). Next steps: address IEEE 802.11 comments. Design Guidelines (Bernard Aboba) ================= Design guidelines has made slow progress, and it is needed for other documents. This is not a good combination. There has been discussion on list and there appears to be an emerging consensus that the document should focus on documenting the current data model but not etending it. The description of the current model should be thorough, and should recognize but not deprecate existing formats. Overall, it is important to articulate design principles. Next steps: Take out the motivation and "problem solutions", and rewrite Section 7 so as to be compatible with existing practice. Also need to expand the discussion on standard and VSA data models. Bernard asked for an editor. Glen Zorn commented that he had taken the action item at a previous IETF to be the editor. He admitted shirking his duties. Asked for assistance with how to edit XML version of draft. Bernard to help. Crypto-Agility ============== Requirements for RADIUS Cryptoagility (David Nelson, channeled by Bernard Aboba) ===================================== What is the goal of crypto-agility? * To provide a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. * To provide for the dynamic installation and negotiation of cryptographic algorithms within protocol implementations. Bernard: Do we really mean "dynamic installation"?? Glen Zorn: I hope not. Bernard: This seems like a bad idea. Glen Zorn: What do we mean by negotiation? This is worse than the previous requirement. Negotiation of crypto algorithms is harder than just adapting to new crypto algorithms. Bernard: What do you think it should mean? Glen Zorn: Negotiation in RADIUS means providing a hint with an accept/deny reply. Should we replace the term "negotiation" with something different? Current state of Affairs RADIUS uses MD5 for a MIC: this has not been compromised by the MD5 collision attacks. RADIUS uses MD5 for a stream cipher to "hide" attributes. This mechanism has known issues (e.g. known plaintext attacks, similar to WEP). Progress toward MD5 compromise is resulting in a movement toward deprecation. Requirements Discussed the need for replay protection as a requirement. Glen disagrees with the MUST requirement. Suggest getting rid of it. Bernard agrees: this is irrelevant to crypto-agility. Requirement to be struck from the slides. Dan Romascanu: Why do proposals not need Diameter compatibility? Bernard: A RADIUS/Diameter gateway will just check the security of the RADIUS packet and translate into Diameter. Agree that Diameter considerations may still exist in document, but may just mention it's a no op and there' s nothing that Diameter needs to do. Glen raised that point that addition of the crypto-agility to Radius is in conflict with the mandate that no new functionality be added to RADIUS. Bernard clarifies that this is about adding no new functionality that isn't directly relevant to crypto-agility. Suggests finessing the wording in slides. Dave Kessens commented that crypto agility is an important topic and very important to get work done in a timely manner. Group needs to reach rough consensus quickly. Bernard pointed out that RADEXT has many outstanding work items that should be completed soon. Crypto agility is the highest priority item. RADIUS + DTLS (Alan DeKok) ============= Alan: The security of RADIUS is "inventive" - suffers from a number of attacks. We can do better. TLS solves all the requirements: integrity, encryption, negotiation. Designed by people who understand crypto. The Good: TLS has been implemented and deployed for RADIUS security. RADIATOR is using "RADSEC": RADIUS over TLS. Other implementations to follow. The bad: Using TLS over TCP introduces some issues. RFC 3539 notes some issues with AAA & TCP. Solution: Datagram TLS RFC 4347 has recently been published. Other WGs are using it; open SSL supports it. Preliminary investigation: DTLS protection of RADIUS is harder than it looks. DTLS may eliminate use of shared secrets but for this draft use of certificates is out of scope. Alexis R.: How does load balancing work? Alan: If a client has a relationship with 10 different servers, it will have 10 different DTLS sessions. Bernard: How would use of multiple service-type attributes work in a single RADIUS packet? Alan: The initial NAS request will only have a single service-type to advertise DTLS capability on the standard RADIUS port. Once DTLS is established a standard RADIUS exchange (with service-type, if present) commences. Bernard: Wouldn't this expose the DTLS session startup to attack? Attacker can crack MD5, then prevent DTLS from being negotiation. It seems like it would make more sense to utilize DTLS on a separate port rather than "up negotiating" -- this would prevent "bidding down" attacks. Group concurs. Glen thinks there is a problem with usage of service-type as advertisement for DTLS. A server that doesn't support the unknown service-type usually treats it as a hint. Alan pointed out the large computational expense in setting TLS sessions. Alan discussed a worst-case scenario consisting of a RADIUS proxy receiving hundreds of requests that will trigger need to establish multiple DTLS sessions with home server. Computation expense may hit proxy hard. Joe Salowey suggests usage of session resumption to lessen negative effects. RADIUS Crypto-Agility (Joe Salowey) ===================== Joe Salowey: One goal of this document is to securely transport keying material; it also provides strong authentication for any RADIUS messages. Attributes include MAC-Randomizer, Message-Authentication-Code and Keying-Material. Keying-Material attribute An application-id and key lifetime is associated with the key. Bernard: How does the key-lifetime in this attribute interact with the existing Session-Timeout lifetime? Joe: They are independent of each other. Bernard: What happens if the Session-Timeout is shorter than the key lifetime in the attribute? Joe: the smaller of the two attributes will determine the key lifetime. You would probably want to adjust the Session-Timeout to match the key lifetime. Bernard: If the attributes need to match, why are both of them needed? Bernard: The randomizer is less about replay protection than freshness? Joe: yes. It is about tying the request to the response, which is different from replay protection Dan Harkins: freshness for... what? Joe: Freshness might not be the right word. Current CoA has insufficient randomness in packet to differentiate one request from another... Bernard: Randomness is there for MD5 stream ciphers? Dan: AES keywrap doesn't require an additional randomizer because you're assuming that what you're encrypting (a key) is itself random. Dan: randomness of the message space is big enough that you don't need additional randomness. Glen: MAC randomizer used to be called Nonce. It's substituting for the authenticator that makes the message authenticator attribute actually work. It's not in CoA or Accounting, the random Request Authenticator isn't there. It makes the Message Authentication Code work. The MAC randomizer is echoed in response packets. Bernard: The problem in 3576 was a circular dependency. The Message-Authenticator depended on the Request-Authenticator field, but the Request-Authenticator in a CoA or Disconnect-Request is not random, it is a MIC that depends on Message-Authenticator. The circular dependency is fixed in RFC 3576bis. Glen: The authenticator is hash of the rest of the message... The circular dependency is solved, but there's no randomness in a CoA or Disconnect-Request. Alan: solving a circular dependency is different than providing randomness that doesn't existt in an Accounting-Request. Glen: There is a naming problem. This is happens to be a random number, but it's not really a nonce. Crypto-Agility Features Rationale: draft-zorn-keywrap extends the RADIUS framework, is re-usable in various situations. Features: * MAC No key management provided is. Keys are "magically" provisioned. * No reliance on particular key derivation methods. * Application Id identifies key usage. * Crypto-agility is supported. Encryption & MAC algorithms are replaceable, providing cryptoagility for message authenticaiton and common key encryption attributes. Only necessary keys are encrypted not whole attributes. Dave Nelson: How do we get interoperability without specifying the "magic"? Joe: The "magic" is out of scope of the document. You could use any mechanism for managing the keys. Dan: This document depends on a whole bunch of key identifiers, all completely unspecified. Looks like giant covert channel is being specified. Bernard: In RADIUS, the "key name" is just the IP address of the client and server. If there is only one key, you don't need a key name. Alan: Why would the RADIUS client and serfver share two keys for the same purpose? Joe: The document doesn't specify a key management scheme, but it seems useful to have a way to identify keys, such as to enable manual roll-over. Bernard: DNSSEC also supports key rollover, but people are questioning why it is there. If we are using AES for encryption, it will take a long time to encrypt enough data to enable a "birthday attack" - do we really need key rollover? And if we do need to change keys, why can't this be handled the same way as it is done today? Dan: naming of keys is important, Housley criteria says you have to do this, but these keys used by endpoints. Why is a distinct name needed? Specification of the content of the key Id's is not needed in a standard. If you want this, create a VSA. Joe: key management is outside scope. Interoperable implementations work with manually entered keys & key Ids. Hannes: regardless of where the protocols run, you still need key naming. Key identifiers are opaque, set by outside means, that's done in many working groups. Joe: key management scheme would be good to develop. Key Id's could be zero for all I care. David Nelson: Do we need to develop a new key name or just reference an existing scheme? Dan: naming a key is important, RADIUS is just a transport. Name has to be known by user & generator of keys, why does RADIUS care? Bernard: If only manual keying is used, the key-Ids are just more information for the administrator to enter. The document doesn't specify a naming scheme. If an automated key management protocol is used, then this proposal will not interoperate unless that mechanism is also specified. Dan: How do I process a message with an unknown key ID? what if it doesn't make any sense in the context of a RADIUS client? Joe: If you don't have a key corresponding to the keyID, then authentication will fail. Dan: Why does it need to fail? RADIUS wouldn't fail unless there was a key mismatch. Hannes: in EAP, you have an identifier, and name the key.. many examples of where this is done. Bernard: There is an existing specification for the EAP-Key-Name attribute, both for Diameter and for RADIUS (RFC 4072). So it would seem that the key naming scheme in this document overlaps with an existing standard. Joe: That's fair. But you could be transporting keys other than EAP keys. Bernard: So the document adds key management new functionality beyond what is currently in RADIUS and Diameter? Joe / Glen: No. Existing keys could be used to send anything. Bernard: But RADIUS and Diameter don't have specifications for generic key transport, only for transport of the MSK and the associated key name. There is no charter item enabling development of a mechanism for transporting arbitrary keys in an arbitrary context. Joe: This document can transport keys beyond EAP. Bernard: Right. But that's outside the scope of the RADEXT WG charter. Glen: Why this is incompatible with the EAP key naming scheme? Bernard: There are existing attributes defined in Diameter for EAP key names. Glen: We can change draft so that if application type is EAP-MSK, then the key ID doesn't exist. Joe: these are all good comments. This approach is different from DTLS, has its own problems and benefits. Bernard: So far I have heard lots of comments about the key transport functionality and use of multiple keys between RADIUS clients and servers, but there have been no objections to the crypto-agility aspects of draft-zorn-keywrap. Can we handle this aspect of the specification first? Hannes: comment on key management. Posted email to list. Manual config, leverage IKE work with domain of interpretation, new type of approach, which leverages domain of interpretation to ... (?) combine DTLS proposal, and derive keys to use for this purpose Dan: The IKE Domain of Interpretation is a perfect example of why it's a bad idea. I'm sorry I put it in there. It's always the same, nobody ever changes it. Dan: It's a good idea to use AES-Keywrap to protect keys. The core idea is great. But it has so much excess baggage. Bernard: Are there any issues with the crypto-agility portion? Alan: how does this address protection of attributes such as Tunnel-Password, CHAP-Password, etc.? That is one of the requirements. Glen: it doesn't. There's another draft about encrypting attributes which does address it. The other draft concatenates one or more attributes, encrypts them and sends them. It also supports crypto-agility, can use any algorithm you want. Joe: Default was AES-CBC. Bernard: Could this be used to protect CHAP-Password, User-Password, etc? If so, then I think this other document is also needed to satisfy the requirements. Glen: will send email asking for other draft to be considered: Hao: Can we standardize encrypting attributes separate form randomizer? Bernard: If we can separate the work on crypto-agility and attribute encryption from the key transport issues, then this would enable us to move forward more quickly. Glen: Not sure how you'd do that. crypto-agility is part of the attribute. Bernard: Do you negotiate the MAC ciphersuite as part of keywrap? Can you separately negotiate the keywrap, attribute encryption and MAC algorithm? Glen: OK Dan: There's an IV defined.. why? Joe: for AES-keywrap, you don't need to define an IV, because AES-keywrap defines an IV. IV could be part of the encrypted data structure... Joe: Next steps: Draft in rev 12, extensively reviewed, approach vetted by NIST, multiple interoperable implementations (Cisco, 3eTI) Hao: are we all OK with requirements? Bernard: Glen will post changes to list. Bernard: We Will use updated requirements to evaluate proposals. We don't have to pick just one. Multiple proposals can be advanced as experimental or informational if there is no consensus. Most important thing is to move forward. We will ask submitters to address requirements. RADIUS Pre-Paid Draft (Bernard Aboba) ====================== Bernard: This document has been stuck, waiting for completion of design guidelines. It is needed by WiMAX Forum and 3GPP. Should this go forward as an Informational RFC using VSAs? The WG can review it, but by using VSAs we will bypass all the discussion on compliance with the standard RADIUS data model. Sub-attributes will be ok. Glen Zorn: This is a good idea. Hannes: I will work on this. We can submit the document soon after IETF 68.