Minutes of the RADEXT WG at IETF 71 Friday, March 14, 2008 9 AM - 11:30 AM Chairs: Bernard Aboba David Nelson Scribes: Clint Chaplin, Dan Harkins Document Status (Bernard Aboba) Published as RFCs: RFC 5080 (Issues and Fixes) RFC 5090 (Digest Authentication) RFC 5176 (Dynamic Authorization) Completed WG last call: Attributes for Filtering and Redirection Design Guidelines Extended attributes In WG last call: draft-ietf-radext-management-authorization-02.txt RADIUS design guidelines, Alan DeKok channeled by Dave Nelson Minor clarifications since -02. Asks for feedback on assumptions of RADIUS and would like text. Draft has completed WGLC but Alan is working on an -03 document. -Bernard: document is only design guidelines for attributes but are there things you can do with attributes outside the normal assumptions? That's the request. Extended Attributes, Bernard Aboba -00 document completed WGLC, 2 comments received, leaves 3 open issues. New version, -01, was posted which changes TLV format but that was not one of the comments. So there is a need to determine whether the changes represent the Consensus of the RADEXT WG, since editors are not allowed to make arbitrary changes to documents in WG last call. Changes: Ext-Type field is now 2 octets rather than 1. Also, the RADIUS Extended Attribute format now applies to existing attributes not just extended ones. Issues include diameter compatability-- how is this larger space mapped into the diameter AVP space?-- and RADIUS backwards compatability-- how does a legacy server deal with standard attributes in extended format? - Dave Nelson: Did we have WG consensus on these changes? If not, how did they get into the document? What is the conflict with Diameter compatibility? - Avi: Get diameter to reserve a block high up in the numberspace and map that way. If we're not mixing the extended and standard space then there is no problem. - Bernard: yea, that would work but it gets confusing when we mix the legacy stuff, because then the new extended attribute space would conflict with existing Diameter AVPs. Also, do standard attributes sent within the new format get mapped to Vendor-Specific AVP 26 in Diameter, thereby breaking existing RADIUS/Diameter gateways? - Dave Mitten from jabber: yea, I still have that issue! - Bernard: what are the opinions in this room? Let's talk about: 1. the increase to 2 octets as well as 2. the encoding of standard attributes in extended format. - Avi Lior: 1 octet would mean that when we run out we'd need another vendor type. Which would be OK, but, he's concerned that when we add octets we'll hit a 4k limit on packet sizes. Not really against, doesn't care, just putting it out. No comment on #2. - Steve Hanna: more of an opinion on #2. What is the argument for allowing existing attributes to be encoded in the extended attribute format? - Dave: reported upside is you can now group existing attributes. - Steve H: But that's not defined so there is no upside and there is a downside so he's opposed to #2. WRT #1, as soon as we fill up the first 256 we could choose a new OID and issue a new RFC and get another 256 but that seems like a lot of overhead. But then we have an additional octet. Still seems worth it to him. Bernard Aboba: You could allocate more than one attribute type now, to avoid opening up the RFC again later. Alan DeKoK (from Jabber): says that unless there's some compelling reason we should resist gratuitous changes. - Bernard: WIMAX compatability was also an issue, no? The original format was a superset of the WiMAX VSA format. - Alan DeKoK (from Jabber): Glen Zorn had reasons that explained in email but I don't think it's a good idea. - Bernard: Consensus call in the room: Do you support the increase in the Extended Attribute space from one to two octets? 7 yes, 1 no Do you support enabling existing RADIUS attributes to be encoded within the Extended Attribute format? 2 yes, 6 no - Avi: will we also take this to the mailing list? - Bernard: yes. We started a mailing list discussion on that. * RADIUS authorization for NAS management, Dave Nelson. First WGLC completed in October 2007. A few issues were resolved in -01 and -02, and a 2nd WGLC is on now. An ISMS WG item depends on this draft. We will wait for WGLC to complete as well as completion of discussion on the mailing list. Bernard: The draft supports "Confidentiality without Integrity Protection". Does this really make sense? You could do it, but it's probably not a good idea. - Dave: yes, you pointed out that confidentiality with no authentication is problematic. Can I can remove this? - numerous from the room: good idea! Bernard: Another issue is exactly what the security options mean when sent by each side. As I understand it, the NAS does its security negotiation with the management station before sending the security options to the RADIUS server. As a result, the options mean "here is what I have negotiated, take it or leave it". It is not a "hint" to the server about what the NAS could negotiate, since the negotiation has already completed. If the security option received from the server is not identical to what the NAS negotiated with the management station, then it is treated as an Access-Reject. This raises some questions: How does the user know that they were denied access because their integrity/confidentiality settings didn't match the network? Does the user know what went wrong or how to fix it? This is likely to cause a user to call the help desk. Is there a way to make this less brittle? - Dave Nelson: well this is really only for mgmt and that's a much smaller pool. There is always tension between high security and high ease of use. - Bernard: wonders whether it's possible for the information to get back in time to influence the security negotiation. IEEE 802 attributes, Bernard Aboba. This document has not changed from the last meeting. The current document incorporated attributes usable to IEEE 802.11r, but has not yet incorporated attributes for IEEE 802.1af or IEEE 802.11s. That is the next step. RADIUS support for EAP reauthentication. Lakshminath Dondeti is not present, so this item was skipped. RADIUS crypto-agility, Dave Nelson We have established WG consensus on the requirements, which are captured in an Internet Draft. However, there have been issues brought up by the IESG's changing requirements, which we discussed at IETF 70. In order to end the discussion, we have captured the requirements in an Internet-Draft and are proposing to send it to the IESG for approval. The draft should be reviewed on the list and then we'll do a WG last call. - Clint Chaplin: when will we accept this as a wg document? - Dave Nelson: well we usually wait until the group is happy with it. - Dan Romascanu: when will we bring in the security area? - Dave: Plan was to do this after the WG last call. - Dan R: well why don't we let them participate in WG LC? That will invite more comments. - Dave: lets clean it up, get consensus, and then we'll do that. - Dan Romascanu: is this intended to be informational? - Dave Nelson: purpose is to write down the requirements and let IESG pass judgement. We want to put a stake in the ground and let the IESG comment. - Bernard: since this has been dragging on for a long time maybe we should get a consensus call in the room to make this a WG work item. It might be faster. Current draft doesn't talk about crypto problems w/RADIUS-- "barely adequate" in 1995, and 12 years later it's beyond the pale. - Hannes: let's just make this into a wg item. It's just a requirements document. I don't like this repeated asking: are you sure? are you sure? - Dan R: is there a better way to put this behind us if we don't adopt it? - Hannes Tschofenig: right. - Bernard Aboba: Consensus call: How many want to make this a wg work item? 11-0 in favor. - Avi: it might be worthwhile asking why we're doing this if it's not in our charter? - Dave Nelson: well we make the interpretation that it's not a "new" scheme it's a fix. - Avi Lior: that's a bit of a stretch. Why is this receiving an exception when it's not in the charter. - Dave Nelson: it's a milestone in the charter and was approved by our AD. - Hannes: I don't want process to get in the way of developing useful solutions. - Avi: I have no problem with that but then don't hold up other useful work by saying "not in the charter". I want consistency. - Dan Romascanu: consistency is at the level of doing the right thing. It's a case-to-case judgement. Our discussion with the security ADs have been going on with several years. Having a written document is a good thing. - Avi: ok, but no one's talking about changing the charter. I just want people to be consistent. I've had drafts shut down by people saying it's not in the charter and I want consistency. - Bernard: we will talk about a re-charter later on. David Nelson: We have 3 submissions relating to the requirements. So far, there has not been consensus on selection of one of the three. The plan is to advance all three documents as Experimental RFCs. HOKEY has a req't for a key container attribute. - Glen Zorn: HOKEY doesn't have a requirement for transport of key attributes it has a requirement for AAA to transport keys. - Bernard: I've always been a bit confused by the req'ts for key wrap and for encryption in general. Can somone explain this? Dan Harkins: Key Wrap does deterministic encryption; there is no nonce added. As a result, the assumption is that the material to be wrapped (the key) is random. However, the header of an attribute used to transport keys (e.g. type & length) is not random. So Key Wrap can't be used to encrypt attributes, only keys (which can be carried inside of attributes). - Dave McGrew: there's a NIST specification for keywrap and then there's the general idea. AES keywrap is ok for doing specialized encryption of things like a bunch of little encryptions with keys. However, Key Wrap doesn't resist known plaintext attacks, only adaptive chosen ciphertext attacks. - Lakshminath: keywrap argument seems to say that if you have a weak key then it's bad and I'm not so sure. RFC 3394 (AES Key Wrap) doesn't say anything about that. Dan Harkins: The NIST specification does. (See: http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf) - Glen Zorn: it's fine to encrypt anything in a suitably strong algorithm. But NIST doesn't approve other algorithms and they move as slow as an elephant in jello. - Lakshminath: the NIST spec says "key data" not keys. So we can wrap arbitrary data not just keys. - Dave McGrew: well yes there are no options in AES keywrap but that may be limiting. It only provides up to 64 bits of integrity protection and that may not be sufficient for some people. - Bernard Aboba: It sounds like key wrap algorithms are actually *weaker* than general purpose algorithms such as AES CCM. What is the security goal of key wrap? Has this ever been defined? - Dave McGrew: Rogaway published a paper on this: (see http://web.cecs.pdx.edu/~teshrim/keywrap.pdf) - Dave Nelson: let's finish the slide deck We complete WGLC on the requirements document and then a call on the list to proceed advancing the 3 drafts as experimental. Ensure that the resulting encrypted attributes draft meets crypto-agility requirements. We will require editors to address all open issues first to demonstrate a willingness to cede control to the IETF. All aspects of the specifications will need to be provided. No "hidden fields" allowed. IPR will need to be disclosed. Now we're in open discussion. - Glen: I am not going to speak for HOKEY and say this is "OKEY DOKEY". It seems weird to have a security area WG depending on an ops area WG to define its security for it. I am not going to agree to this for the HOKEY WG and it's not obvious to me the HOKEY WG will either. Bernard Aboba: In the HOKEY WG meeting, there was discussion about restricting the scope of work to key transport relating to HOKEY, specifically. - Dave Nelson: Whether AAA should be in the security area or not, well.... these are legacy protocols and HOKEY wanted to use AAA. AAA has historically been an ops wg and we need to finish our crypto-agility work. - Glen Zorn: There are two drafts, one talks about encrypting attributes, the other about transporting keys. What sort of end-to-end security requirements do we need to transport these keys? One thing that's bad is RADIUS over IPsec. DTLS, maybe. But I think we would prefer to use an encrypted attribute or a key wrap. One reason is for immediate certification. The keywrap algorithm has been confirmed. There are systems that use it now that are NIST certified. - Dave Nelson: HOKEY can provide security requirements to RADEXT WG. RADEXT WG should focus on the generic problem, and if anyone else wants to use it to solve a specific problem, that is a bonus. - Steve H: the need for RADIUS crypto-agility goes beyond HOKEY WG. The requirements for other needs also goes beyond encrypted attributes. - Dave Nelson: I think it's reasonable to advance them all. I think the difference between a NIST approved keywrap algorithm and a NIST approved generalized encryption algorithm is not a big difference. If we get an encrypted attribute draft that does keywrap then we can move forward. - Bernard: Since this item is about crypto-agility, why can't algorithms for multiple purposes be negotiated? You could negotiate a key-wrap algorithm, a general purpose encryption algorith, an integrity algorithm... Why not? - Joe Salowey: As a co-author, I have no problem supporting a null keywrap algorithm. - Dave Nelson: RADIUS Crypto-agility supports a superset of things that have been discussed: key-wrap, encryption, integrity protection. - Bernard: One issue is RADIUS/Diameter compatibility. If the desire is to define one attribute that runs within either RADIUS or Diameter, then it is best for that attribute to be agnostic. Transmission layer algorithms, or solutions which encrypt entire attributes satisfy that constraint. Keywrap algorithms can also satisfy the constraint, if there is a null keywrap algorithm. - Glen: I'd like to clarify. I never said the need for radius crypto-agility is to satisfy HOKEY and I never said that anything we do here will even satisfy HOKEY. And furthermore, it's immaterial. Whether we choose an encrypted attribute or not-- for diameter compatability-- we have hidden attributes that get encrypted and passed in the clear. - Steve H: I was not saying that. I think we're actually agreeing. - Lakshminath: in my slides I said that we could use keywrap as long as the keytype indicated null encryption. Why wouldn't that work? - Glen: well with some schemes, like RADIUS over IPsec, you can assume security is there but you don't know. And if one hop doesn't have it you're screwed. There is no way to know if IPsec is there. Setting the encryption algorithm to null would be very dangerous. - Bernard Aboba: Couldn't the same problem occur with a keywrap attribute? Presumably the attribute would be encrypted/decrypted on a hop-by-hop basis. So all hops would need to support it. - Hannes: Glen's document is just about protecting the key, it could be hop-by-hop or not. The other draft does negotiation for crypto-agility. So I don't think the high-level issues got expressed correctly. - Avi: can you use your keywrap draft to encrypt other things? - Glen: no, only keys. - Avi: well this is a problem then because we want to encrypt other things. - Glen: well we have another draft to do just that! If keywrap becomes a wg item then I cease to be an author and become just an editor and then I'll do what I'm told. - Joe Salowey: we need to be sure in the security considerations about setting a null encryption method. Splitting keywrapping from an encrypted attribute container, there are issues about encrypting bulk data. - Dave: yes, the requirements we captured were slightly different than just the keywrap draft. That draft actually pre-dates our instruction to go off and do crypto-agility but it came up as a potential solution. - Hannes: the more important issue is the authentication and key exchange, rather than how you protect the keys. You have some credential that you then use to generate a session key. In Glen's proposal you use the key to protect things. - Bernard: we had a discussion at IETF 70 and AKM is not a requirement for crypto-agility. I believe that argument is off-the-table. - Hannes: I don't think so because one solution doesn't provide it and there's another RFC by Bellovin that says static keying is out-of-scope and you need automated key management. - Dave: one of the requirements captured was that AKM was needed if the number of keys was n^2. That's not the case here, in the hop-by-hop case. - Hannes: but the state of the art in this subject is Diameter and why do we want to go below the state of the art? - Dave: why do we want to turn RADIUS into diameter? I'm not saying we don't want to use AKM. But what we were asked to do by the security ADs was to make the base security in RADIUS agile so it's not so broken. - Hannes: this really bothers me! The work in the IETF is guided by the security ADs? They provided a pointer in their review. But this is a tiny detail and a big giant problem next to it, so do we solve the tiny detail or the big problem? - Bernard: we'll be driven by consensus on how to go forward. That's why we need a requirements document. - Glen: ok, so this really bothers me. Neither TLS nor DTLS are magic bullets that make things all wonderful. There are big problems with key distribution and those keys don't exist today. You need to rework the entire system. - Hannes: yes, I know that. But if you think crypto-agility is your problem then you don't know what your problem is! - Stefan: if you're serious about the security it is possible to do this key distribution. - Glen: I'm not saying it's not possible. What I'm saying is that there are large numbers of service providers who refuse to change their RADIUS servers so you can't just push in a PKI and that they'll eat it up then, you should talk to the guys I've talked to. RADSEC, Stefan Winter RADSEC has been implemented in RADIATOR (Mike McCauley), as well as in RADSEC proxy (Stig Venaas). FreeRADIUS support will come in the next year. Klaus Wierenga has indicated that he has made a presentation within Cisco, and there has been some interest (though he does not speak for Cisco). Failover tests have been conducted. RADSECproxy outperformed RADIATOR because it has Status-Server support, allowing it to detect failures more quickly. If this is such a good thing maybe we should make it a MUST. - Dave Nelson: Status-Server is not currently documented as an RFC. - Bernard Aboba. The RADIUS code of 12 is reserved for use by Status-Server (experimental) in RFC 2865 Section 3, but there is no RFC. - Stig Venaas: Status-Server is being used, based on Alan DeKok's draft-dekok-radius-status-server-02.txt. RADSEC is deployed in EDUROAM. There's an EU root CA and each country has a cert, apparently. - Dan Harkins: you could eliminate proxies using this. Have you? - Stefan Winter: you could use DNS SRV to locate the RADSEC server corresponding to the realm in the NAI, and contact it without going through a proxy, but there are some operational issues with some institutions. They don't want to let everyone access their server. Diameter can also solve the problem, but Access Points do not support Diameter (RFC 4072) for wireless LAN authentication. - Alan DeKok (through jabber): proxies could be eliminated in Eduroam but not in every other deployment. - Stefan: yes, in the case of Eduroam, we could mostly get rid of them. One issue is that even if you discover the server via DNS SRV there is no way to know that's the end of the chain. You could just be contacting the outward facing proxy within a realm, which will forward the query to another proxy or server within the realm. So you can't trust that you're at the end of the chain; the end of proxies is not there yet. Dynamic Discovery. If authentication realms are supported using the RFC 4282 NAI format, and you have RADSEC and DNS SRV as well EAP, then you can automatically route an authentication request to the correct home server and there are no negotiations needed between the visited and home domains. - Hannes: essentially the openid usage is largely orthogonal. - Glen: I am going to agree with you. I'm sure you can do this and I think you can do it in Diameter but nobody does. There is no interest. The mechanics of setting up a roaming agreement are way more complicated than just finding the right RADIUS server. - Hannes: yes. - Glen: for RADSEC it can work, but not for RADIUS - because you need to set up a shared secret. - Stefan: There has been lots of good feedback on the list on the RADSEC I-D. We have been asked to consider SCTP, as well as about MIB considerations. If RADSEC draft is adopted some rewording is needed. What's the relation to DIME/Diameter? No conflict anticipated. I think this is a good thing and it should be adopted as a WG work item. - Glen: there's a difference between market conficit and standardization conflict. - Hannes: at the end it's a marketing choice. It's wrong for us to think that we can make that choice here. - Steve Hanna: There are issues with proxy chains and EAP-TLS authentication with RADIUS. In EAP-TLS, the long certificate chains can result in many round-trips. When proxies are present, this can result in long authentication times, or maybe even authentication failure (where there is packet loss). Were those issues you encountered, fragmentation, reliable transport, dealt with by radsec? Consensus Call: Should RADSEC be adopted as a RADEXT WG work item and the charter changed? 9-5 in favor. It will be taken to the list. - Dan Romascanu: this work has been discussed in other instances. Stefan tried to get a roaming BOF formed that would include RADSEC but it didn't happen because the belief was that it looks close to RADIUS and it should be taken to this group. Do people think it should be a different working group or maybe an experimental track? - Alan DeKok (via Jabber): maybe a AAA proxy security BOF in Dublin? Consensus Call: What about creation of a RADSEC BOF and a separate WG? 3 yes, 2 no. RADIUS packet fragmentation when using EAP, Stefan Winter. Some EAP methods require the client to send a lot of data to the server, e.g EAP-TLS. The client can send up to their own MTU, then the authenticator encapsulates the EAP message in RADIUS and the resulting RADIUS packet may be larger than the MTU of the link from the authenticator to the server. This can create problems in practice. Can the supplicant be told how big the EAP message should be? - Avi Lior: isn't there already a mechanism to negotiate the mtu? - Stefan: There's the Framed-MTU attribute but that is transmitted from the server to the authenticator. It doesn't go to the supplicant. - Dan Harkins: this will be resisted by people like 802.11 who want to send less bigger frames, not more smaller frames. - Clint: isn't this because the client has no clue how much overhead will be added? - Bernard: In path-mtu discovery if the packet is too big, it doesn't go through and maybe you get an indication of that, such as an ICMP Packet too big error. So you can use the ICMP feedback (conventional MTU discovery) or the loss (Packetization layer path MTU discovery) to figure out what is going on, and discover the MTU. Here, the EAP peer could discover a problem if his packet doesn't get through. If the Request is transmitted again and again, the peer could infer that the MTU is too large and decrease it. But if the problem is intermittent, such as if the peer MTU is less than the link MTU, and it's just an intermittent loss problem on the path between the authenticator and server, then it's hard to figure out. - Stig Venaas: one thing is the link mtu but you may not want the same one for the EAP messages. There's an "eap mtu" and a "link mtu" - Bernard: There was discussion in 802.1af about adding the link mtu in the advertisement. But here the EAP MTU from the RADIUS client to the RADIUS server is potentially variable, isn't it? Wouldn't it depend on what other RADIUS attributes were in the Access-Request? - Stefan: yes, that's true. The idea is that the authenticator would add a "this is how much I'll add" and the proxy will increase that and the final value is sent back by the final AAA server. - Stig Venaas: I don't think fragmentation is a bad thing. Once in a while fragments will be dropped. - Stefan: but sometimes fragments arrive out-of-order and firewalls will drop them. -Bernard: Sometimes firewalls drop them even if they arrive in order. Roaming Extensions for radius, Vamsi Krishna Gondi This document proposes new extensions for network selection, handover management, security context management, mobility management, and presence and qos support. Open issues on security, process mechanism, packet data, and IANA considerations. Looking for feedback from other researchers. Hannes: Suggest that you look at SDOs activities: WiMax, 3GPP, 3GPP2 that are looking at handovers. Looks like the server needs to know everything about the network. IEEE 802.21 also doing handover work. MEETING ADJORNED.