Last Modified: 2004-07-14
The IETF has recently completed work on the Diameter Base protocol. In order to support the deployment of Diameter, and enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.
Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:
- All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No new security mechanisms will be defined for protecting RADIUS. - No new commands will be defined.
The immediate goals of the RADEXT working group are to address the following issues:
- RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues.
- RADIUS implementation issues and fixes. This document will address common RADIUS implementation issues and describe proposed solutions.
- Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to correct known errors, add support for privacy and internationalization, and provide more details on routing.
- Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will include within it a specification for interoperation with Diameter Credit Control.
- SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability.
This document will be upwards compatible with the Diameter SIP application, and conform to existing IETF RFCs on HTTP Digest, including RFC 2617, 3261, and 3310.
- LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability.
- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest changes are required to address this issue. MIBs for RFC 3576 are also needed.
|Dec 04||Updates to RFC 2618-2621 RADIUS MIBs submitted for publication|
|Dec 04||RADIUS design guidelines submitted as an Informational RFC|
|Dec 04||SIP RADIUS authentication draft submitted as a Proposed Standard RFC|
|Jan 05||LAN attributes draft submitted as a Proposed Standard RFC|
|Feb 05||RADIUS implementation issues and fixes submitted as an Informational RFC|
|Feb 05||WLAN attributes draft submitted as a Proposed Standard RFC|
|Feb 05||RFC 2486bis submitted as a Proposed Standard RFC|
|Dec 05||RADIUS Prepaid draft submitted as a Proposed Standard RFC|
|Dec 05||RFC 3576 MIBs submitted as an Informational RFC|
RADIUS Extensions (RADEXT) WG
Minutes of the Thursday August 5, 2004 Session
Agenda bash - no changes.
Radius issues and fixes presentation: Dave Nelson
- No explicit attribute tagging for optional vs. mandatory in RFC2865
- Apparent text conflict among sections of RFC2865 on "mandatory" behavior
- Need to change or clarify existing implementations/standards?
- No, more along the lines of documentation fixes.
- Need to be clear moving forward about attributes being mandatory vs. optional.
- Draft output will be informational
Request ID supplementation/augmentation
- Issue is that the Request ID is only 8-bits
- Is existing advice (e.g. RFC) adequate?
- How many implementations of this? Three hands.
- Allocate as many IDs to ports as needed; no problem
What's an SSA?
- SDO-Specific-Attribute vs. VSA
- SSA has more formal syntax than VSA
- Why is this an issue? Isn't an issue yet.
- Proposed to assist SDOs in doing RADIUS standards work outside of IETF.
3576/NASREQ Session change dynamically; how do you notify accounting?
- start/stop vs. interim messages
- interim messages often ignored.
- start/stop releases all resources.
- possible solution: attribute in Authorize-Only Access-Accept
- Q: We currently use final stop message for billing information,
we would prefer start/stop.
- Q: Are resources released on a stop message?
- A: Yes, we release IP addresses on a stop.
- Q: Not in 3GPP; you send a session continue attribute instead.
RADIUS Authorize only messages
- RFC 3576 COA messages
- Must semantics be complete?
- People are no using Authorize-Only messages to authorize Service Instance or for prepaid quotas.
- Problem is that may have to include >all< previous information in Authorize-Only message.
- Q: Has this affected anybody in room?
- A: We have assumed that subset only is OK, and we've worked
with partners to implement that.
- A: Itís not explicitly part of standard to do that.
- Need further discussion on the RADEXT list.
Data Model issues: Bernard Aboba
- RADIUS dictionary is not defined in any RFCs
- Client doesn't need to have dictionary; always has to change. (Results of research through various RFCs for data types)
- RFCs only have 4 fundamental data types
- Q: Framed-IPv6-Prefix design worked OK.
- A: Yes, but should have been a string.
- Q: still need to parse. Yes
- Q: Server doesn't need to parse string: passed to back end authenticator
- Q: several obscure types never actually used: time stamps, etc.
LAN Attribute Extensions: Farid Adrangi
- Attributes useful for wireless roaming, but could still be useful for other uses.
- User Identity Alias Attribute
- Q: Don't know which is correct, especially if multiple ones; not that it's opaque.
- User name is used for routing purposes, User Alias is designed to be unique.
- Q: Why all the alias types, when there is only one use for this attribute?
- A: For flexibility, feedback from GSM operators...
- Q: This defeats anonynimity.
- Generic RADIUS Application Capability Attribute
- Enable home RADIUS server to discover capabilities of client
- IP Address Type Options Attribute
- Routable vs. non-routable
- Other attributes
- Went long on presentation; hold further discussion on the RADEXT list
- Most important is User-Name.
- Q: Monday presentation had application stuff; is there overlap?
- A: No
- Need further discussion on the RADEXT list.
RADIUS Data Model Issues: Jari Arkko
- Not all attributes created equal
- That's cool; different spaces for different purposes
- Hard to transfer attributes between spaces
- Can't move from Diameter to RADIUS
- Q: Would it be valuable to survey current VSA usage?
- A: Um, no; too many.
- Q: Mandatory vs. Optional: applicable to these new types?
- A: Would have to be optional
- Q: Is there actually a plan on how we're going to keep parts in sync?
- A: Nope, no plan, and that's the path we are still following.
- Diameter compatibility section necessary in drafts.
- Diameter Vs. RADIUS; wish we weren't still discussing RADIUS at all.
- Vendors don't pay attention to what the IETF does.
- Jari and Farid have presented three options moving forward
- Farid is orthogonal to Jari's
- Q: May not be able to keep both spaces in sync.
- Q: Interoperability may be between WGs as well as on the wire.
- Naming an attribute may be sufficient; don't need to define them
- Q: What are the various options we need to decide between?
- Q: Difference between two groups of options.
- Bernard: Ask group if problems are important?
- Group hum: some sort of capability negotiation is needed?
- A: Yes
- Group hum: easier way to share capabilities between Diameter and RADIUS?
- A: Not as strong, but rough consensus
- Group hum: need to extend attribute type space? More type numbers?
- A: Response "iffy" either way.
- Comment: We'll run out anyway.
- Q: SSAs may become VSAs
- Group hum: need for easier movement between VSA attribute space and and IETF attribute space? Alignment of data models?
- A: Yes
Three additional presentations first, then discussions
RADIUS vulnerability in Wireless: Randy Chou
- Point is to point out practicality of attacks
- How many have read actual draft? About 1/3 to 1/2.
- Use one example of problem: 802.11i encryption keys depend on
RADIUS shared secret.
- Wired sniffing is riskier; wired infrastructure can sense promiscuous adapters
- Shared secret can be easily known; not kept confidential.
- Loss of shared secret is equivalent to loss of certificate
- Q: RADIUS Shared secret isn't equivalent to certificate: certificate is designed to be shared in a wider area.
- Q: Does document have anything about RADIUS over IPSec?
- A: No. Some issues covered in 3579.
- Q: What is the perception of RADIUS Shared Secret? Is root password perceived as similar to RADIUS secret.
- Q: RADIUS been around a long time; any reports on existing or past attacks on RADIUS servers? Wouldn't be necessarily publicized.
- Q: This is a RADIUS problem, not a wireless problem. Taking to the press that it's a wireless problem was irresponsible.
- A: Consequences need to be publicized as well.
- Q: This really is a wired vulnerability, not a wireless vulnerability.
- A: sniffing on wired networks is harder.
- Q: Wired sniffing is mandatory for this attack to happen; no wired, no attack at all.
- A: Agreed
- Q: Can there be Wireless RADIUS servers?
- A: Yes.
- Q: If RADIUS secret is compromised, the user passwords are compromised. Why go for the wireless keys? Can store wireless traffic, and in future when radius secret broken, can decrypt captured traffic
RADIUS Shared Secret Security Amplification: Paul Funk
- Is RADIUS encryption/validation good enough?
- Dictionary attack.
- Attacker must have layer 2 traffic visibility
- Q: Finely hashed becomes the secret. Small final key space allows a brute force that's faster than dictionary/hash attack.
- A: 96-bit key space can't be brute-forced.
- Q: If a utility is used, why not also have the utility throw in a random number?
- A: Want to be able to regenerate final answer easily from remembered information.
- Q: Base64 may be incompatible with some RADIUS product input limitations.
- Q: Why not use RSA instead?
- A: Trying to increase work needed
- Q: Why not just pre-calculate dictionary?
- A: See upcoming slide, also use salt.
- Q: Why do I need to ever know the precursor? I have the final output...
- A: Many people just want to use the pre-cursor, because they >can< remember it.
Transmit keys by RADIUS using AES key wrapping: Glen Zorn
- Make more secure, and satisfy customer requirements.
- Q: Recommend use only one shared secret, rather than two.
- A: two makes more sense, especially for multiple entities.
- Q: Any discussion with NIST? FIPS approval?
- A: NIST has problem with MD5 in RADIUS header, but as long as it isn't relied upon, then OK.
- Q: NIST has no formal statement on this.