AAA-Key Derivation with Lower-Layer Parameter Binding (draft-ohba-eap-aaakey-binding-01.txt)

1
AAA-Key Derivation with Lower-Layer Parameter
Binding(draft-ohba-eap-aaakey-binding-01.txt)

• Yoshihiro Ohba (Toshiba)
• Mayumi Yanagiya (NTT)

2
Background

• Each EAP lower-layer carries its own parameters
  (such as SSID in 802.11)
• Those parameters would need to be
  cryptographically bound to the AAA-Key to avoid
  possible security flaws
• What can happen if the AAA-Key is not bound to
  EAP lower layer parameters?
• The key may be used for a different context of
  the EAP lower layer
• The key may be used by a different EAP lower
  layer
• draft-arkko-eap-service-identity-auth describes
  the channel binding threats in more detail
• Existing solution carrying channel binding
  parameters in EAP methods
• draft-arkko-eap-service-identity-auth
• draft-tschofenig-eap-ikev2

3
Channel Binding within EAP method
EAP Authenticator
EAP Server
EAP Peer
EAP lower-layer
AAA
EAP method run within EAP
Channel Binding Parameter Verification
Channel Binding Parameter Verification
Channel Binding parameter exchange
AAA-Key
AAA-Key
Successful Verification
Successful Verification
AAA-Key Verification
4
Solution Framework

• EAP lower-layer entities make final decision as
  to whether the lower-layer parameters are
  successfully bound to the AAA-Key
• This makes a solution to work regardless of
  whether the EAP authenticator and EAP server are
  co-located or not
• The EAP server that has a trust relationship with
  both the EAP peer and the EAP authenticator
  involves in the process of binding the EAP
  lower-layer parameters to the AAA-Key
• The AAA-Key derivation algorithm is agnostic to
  specific EAP lower-layer parameters

5
key-binding-blob

• An octet-string carrying lower-layer parameters
  that need to be bound to the AAA-Key
• The content of the key-binding-blob is defined by
  each EAP lower-layer
• When the EAP authenticator and the EAP server are
  implemented in different physical boxes, the
  key-binding-blob is carried in a AAA protocol

6
AAA-Key Derivation Algorithm

• AAA-Key KDF(MSK, AAA-Key-name
  key-binding-blob)
• The format of AAA-Key-name TBD
• Scope of AAA-Key
• the pair of a particular EAP peer and a
  particular EAP authenticator

7
Key Binding Procedure (pass-through EAP
authenticator)
EAP Authenticator
EAP Server
EAP Peer
EAP lower-layer exchanges
Generation of key-binding-blob
Generation of key-binding-blob

AAAEAP, key-binding-blob, etc.
key-binding-blob Verification (optional)

AAA-Key Derivation using key-binding-blob
AAA-Key
AAA-Key
AAAEAP, AAA-Key, etc.
AAA-Key Verification
8
Key Binding Procedure (standalone EAP
authenticator)
EAP Authenticator/Server
EAP Peer
EAP lower-layer exchanges

Generation of key-binding-blob
Generation of key-binding-blob
AAA-Key Derivation using key-binding-blob
AAA-Key
AAA-Key
AAA-Key Verification
9
Co-existence with legacy algorithm

• Legacy algorithm AAA-KeyMSK(0,63)
• If EAP authenticator does not send a
  key-binding-blob to EAP server
• If the EAP server is configured to use the legacy
  algorithm, use it
• Otherwise, authentication MUST fail
• If EAP authenticator sends a key-binding-blob to
  EAP server and the server is configured to use
  the legacy algorithm, the authentication
  procedure MUST fail

10
Comparison with existing solution

• Existing solution
• Pros
• No need to change existing pass-through
  authenticator implementations
• Cons
• Requires each EAP authentication method to carry
  channel binding parameters
• Not needed in the case of standalone EAP
  authenticator
• Proposed solution
• Pros
• No need to change existing EAP methods
• Transparent operation for both standalone and
  pass-through authenticators
• Provides a robuster way of key binding (e.g.,
  mis-implementation wont result in successful
  4-way handshake in case of parameter mismatch)
• Cons
• Needs to change existing pass-through
  authenticator, EAP server and EAP peer
  implementations (to support key-binding-blob)

11
Discussion

• Is this solution good?
• If not, we stop here
• Should we choose one single solution or allow
  multiple solutions?

12
Thank you!
13
Back-ups
14
Validating key-binding-blob

• The level of trust relationship between an EAP
  authenticator and an EAP server may vary
  depending on the deployment
• If there is a full level of trust relationship
  between the EAP authenticator and EAP server, the
  EAP server can trust information sent by the EAP
  authenticator as it is
• No validation of key-binding-blob is needed
• Otherwise, validation of key-binding-blob is
  needed
• Validation is based on simple string comparison
  with the expected key-binding-blob value that may
  be pre-configured on the EAP server
• The EAP server would need to know the structure
  of the blob only at pre-configuration time (one
  time) but is still agnostic to the content of the
  blob during the AAA operation

15
AAA Protocol Condiderations

• New AAA attribute Key-Binding-Blob
• Since the length of the blob may exceed the
  maximum length of RADIUS attribute (253 octets),
  the Key-Binding-Blob attribute is defined as a
  fragmentable attribute

16
RADIUS Key-Binding-Blob attribute
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Type Length
L Fragment ID String...
-------------------------
-------

• Type Key-Binding-Blob (TBD)
• Lengthgt4
• L(ast Fragment) indicates the last fragment
• When carried in Diameter, L is always set (no
  fragmentation)
• Fragment ID starting from 0 and incremented by 1
• When carried in Diameter, Fragment ID is always 0
  (no fragmentation)
• String key-binding-blob

17
Discussion

• The EAP server may need to identify at least the
  type of the EAP lower layer
• Otherwise, there could be unfortunate case in
  which key-binding-blob happens to match that is
  generated by a different EAP lower-layer
• How to carry EAP lower-layer type to the EAP
  server is FFS