RADEXT WG Minutes for IETF60 Thursday session

["Nelson, David" <dnelson@enterasys.com>]

IETF 60
RADIUS Extensions (RADEXT) WG
Minutes of the Thursday August 5, 2004 Session

Agenda bash - no changes.

Radius issues and fixes presentation: Dave Nelson
RFC2865
	- 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
	- draft-adrangi-radius-attribute-extension-01.txt
	- 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.


 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>