RADEXT WG

1
RADEXT WG

• RADIUS Attributes for WLAN
• Draft-aboba-radext-wlan-00.txt
• Jari Arkko (for Bernard Aboba)
• IETF 63 Paris, France

2
Document History

• Goal Attributes for existing (and future) IEEE
  802.11 usage
• Potential liaison requests from IEEE 802.11r,
  IEEE 802.11u
• Includes WLAN attributes originally included in
  draft-congdon-ieee802-02.txt
• Allowed-SSID
• Allowed-Called-Station-ID
• Includes RADIUS attributes corresponding to
  Diameter EAP (RFC 4072) AVPs
• EAP-Master-Session-Key
• EAP-Key-Name (already allocated in RADIUS
  attribute space)
• Accounting-EAP-Auth-Method
• Includes attributes described in
  draft-ietf-eap-keying
• EAP-Peer-ID
• EAP-Server-ID

3
EAP Conversation
EAP Method
EAP Method
EAP Method
EAP Peer layer
EAP Authenticator layer
EAP Authenticator layer
EAP layer
EAP layer
EAP layer
Lower Layer
Lower Layer
AAA
AAA
EAP Peer
EAP Authenticator
EAP Server
4
EAP Key Management Model(draft-ietf-eap-keying)
EAP Method
Method-ID
EAP Peer/ Authenticator Layer
EAP Layer
Exp. Type Method-Id
MSK
EMSK
IV (deprecated)
Peer-ID
Server-ID
Key-Lifetime
Session-ID
Channel Bindings
Lower Layer
Mandatory
Key
Optional
5
Flow of EAP Keying Parameters
EAP Method
EAP Method
EAP Method
EAP Peer layer
EAP Authenticator layer
EAP Authenticator layer
EAP layer
EAP layer
EAP layer
Lower Layer
Lower Layer
AAA
AAA
EAP Peer
EAP Authenticator
EAP Server
EAP peer authenticator only (no backend server)
Key
EAP peer server (authenticator pass-through)
6
AAA Requirements

• Replication of keying material
• In existing usage, only the MSK is replicated
• IV is deprecated (RFC 3748)
• EMSK MUST NOT be replicated (draft-ietf-eap-keying
  )
• Transport of other EAP keying parameters
• Session-ID Unique EAP conversation identifier
• Each method has its own unique identifier space
• Peer-ID Server-ID Peer and Server identifiers
  used by the method
• Key-Lifetime MSK/EMSK lifetime, if negotiated by
  the method
• No need for new AAA attribute, can be handled via
  Session-Timeout

7
New Attributes

• EAP-Master-Session-Key
• Darries the MSK exported by the method
• Defined in RFC 4072, allocated as a Diameter AVP
• EAP-Key-Name
• Carries the EAP Session-ID, if exported by the
  EAP layer
• Defined in RFC 4072, allocated as a RADIUS
  attribute
• EAP-Peer-ID
• Carries the Peer-ID, if exported by the method
  (and requested by the NAS)
• EAP-Server-ID
• Carries the Server-ID, if exported by the method
  (and requested by the NAS)
• Allowed-SSID
• Specifies one or more SSIDs which the STA is
  allowed to access
• With EAP pre-authentication, AAA server may not
  know which SSID the STA will Associate with
• Allowed-Called-Station-ID
• Specifies one or more Called-Station-IDs the STA
  is allowed to access
• AAA server may wish to restrict access to one or
  more BSSIDs

8
Security Issues

• Privacy
• Keywrap
• Disclosure to unauthorized parties

9
Privacy

• Privacy may be desired
• anonymous_at_realm or _at_realm NAIs may be used in
  EAP-Response/Identity
• EAP-Peer-ID or EAP-Server-ID are not sent by the
  backend server unless requested by the NAS.

10
Keywrap

• -00 proposes use of AES Keywrap (RFC 3394,
  Section 4.1)
• Protection provided on a hop-by-hop basis
• Options for the Key Encryption Key (KEK)
• Derived from the RADIUS shared secret (-00
  approach)
• Pros
• Requires only a single secret between RADIUS
  client server
• Cons
• If the RADIUS shared secret is compromised,
  attacker can unwrap the key and can also forge
  packets
• Use a cryptographically separate KEK and MAC key
• Pros
• RADIUS shared secret no longer a valuable target
• Obtaining the RADIUS shared secret does not
  permit unwrapping of keys (KEK) or forgery of
  packets (MAC key)
• Can be made backward compatible with existing
  implementations
• Cons
• Requires three shared secrets between RADIUS
  client server
• If KEK and MAC key are based on passwords, they
  are susceptible to offline dictionary attack just
  like the RADIUS shared secret
• Doesnt matter
• Use IPsec to protect RADIUS instead

11
Disclosure

• Disclosure of keying material to unauthorized
  parties is problematic
• See AAA Key Management, draft-housley-aaa-key-mg
  mt-00.txt
• Compromise of RADIUS proxy leads to compromise of
  all RADIUS clients of that proxy (Domino
  Effect)
• Fixing this is a known hard problem
• AAA WG worked on Diameter CMS for several years
  before giving up
• All proposed approaches have some drawbacks
• See Appendix for details
• Recommendation
• Do not attempt to solve the disclosure problem in
  this document
• Consider amending the RADEXT WG charter in future
  to handle this and other security-related issues
  (such as FIPS Certification)

12
Questions

• Should this document become a WG work item?
• What approach should we take to keywrap?
• Do we need to solve the disclosure problem?

13
AppendixDisclosure Prevention Approaches
14
Potential Approaches

• Inter-domain as well as intra-domain support
• Redirect
• DNS-based Key Establishment
• Leap of Faith
• Intra-domain support only
• NAS as EAP peer
• Static KEKs

15
Redirect Approach

• Approach taken by RFC 4072 (Diameter EAP)
• Diameter conversation protected by TLS and/or
  IPsec
• Diameter Agent provides the client with the
  server address corresponding to the NAI realm
• Diameter client contacts the server directly to
  retrieve keys
• Keys protected by TLS and/or IPsec (no keywrap in
  RFC 4072)
• Applicability
• Inter-domain and intra-domain use
• Limitations
• AAA client agent need to support Redirect
• AAA client server need to use certificates
• IKE limitations make it difficult to choose
  appropriate certificates for a given application
• Example AAA client using IPsec to protect
  Diameter as well as Telnet or FTP
• Server will not know if the IKE initiator intends
  to set up a Phase I SA for Diameter or FTP, may
  choose the wrong certificate

16
DNS-Based Key Establishment

• Under development in Terena Mobility Task Force
  (Eduroam)
• RADIUS client utilizes RADIUS server discovery as
  described in RFC 3588
• RADIUS server public key made available via DNS
• DNSSEC used to protect DNS RRs
• RADIUS client establishes direct contact with
  RADIUS server
• RADIUS conversation protected by TLS (RADSEC) or
  IPsec
• Running code now available (RADIATOR)
• Reference Eertink, Peddemors, Arends Wierenga
  Combining RADIUS with Secure DNS for Dynamic
  Trust Establishment between Domains
• http//www.eduroam.org/
• http//www.terena.nl/conferences/tnc2005/programme
  /presentations/show.php?pres_id51
• Applicability
• Inter-domain and intra-domain use
• Limitations
• AAA client server need to store Key RRs in the
  DNS
• AAA client server need to support DNSSEC

17
LEAP of Faith

• Approach
• NAS RADIUS server provisioned with static DH
  keys
• Prior to sending an Access-Request to a RADIUS
  server, the NAS registers with the RADIUS
  server via anonymous DH.
• RADIUS server stores the DH parameters associated
  with each registered NAS
• DH-derived key used to derive the KEK used for
  keywrap of the EAP-Master-Session-Key attribute
• Applicability
• Inter-domain intra-domain use
• Limitations
• Vulnerable to man-in-the-middle attack on initial
  registration
• RADIUS server must store keys for all NASes that
  communicate with it.
• NAS RADIUS server must natively support
  registration mechanism

18
No Proxy

• Approach supported in -00
• Assumes RADIUS client talks directly to RADIUS
  server
• Can be combined with re-direct or DNS-based
  keying approaches to avoid proxy disclosure
• Applicability
• Inter-domain and intra-domain use
• Limitations
• Avoids disclosure only when no proxies are used.
• At worst, administrative overhead is the same as
  the static KEK approach

19
NAS as EAP Peer

• Approach
• NAS RADIUS server have a pre-existing
  relationship
• NAS authenticates to the home RADIUS server,
  derives EAP keying material
• EAP keying material used to derive the KEK used
  to keywrap the EAP-Master-Session-Key attribute
• Applicability
• Applicable only to intra-domain use (no roaming)
• Limitations
• NAS must support EAP, as well as share a common
  EAP (key deriving) method with the RADIUS server
• NAS must have an account on the RADIUS server

20
Static KEKs

• Approach
• NAS RADIUS server provisioned with static KEKs
• Static KEK used for keywrap of the
  EAP-Master-Session-Key attribute
• Applicability
• Applicable to intra-domain use only (no roaming)
• Limitations
• Manual re-provisioning required if KEK becomes
  stale
• RADIUS server must store a KEK for all NASes that
  communicate with it.

21
Feedback?