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) IETF63 EAP WG

2. Background • Each EAP lower-layer carries its own parameters (such as SSID in 802.11) • Those parameters would need to be cryptographicallybound 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 trustrelationship with both the EAP peer and the EAP authenticator involves in the process of binding the EAP lower-layer parametersto 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 : : : AAA[EAP, key-binding-blob, etc.] key-binding-blob Verification (optional) : : : AAA-Key Derivation using key-binding-blob AAA-Key AAA-Key AAA[EAP, 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-Key=MSK(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 won’t 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! IETF63 EAP WG

13. Back-ups IETF63 EAP WG

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 relationshipbetweenthe 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 withthe 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 • Type: Key-Binding-Blob (TBD) • Length>=4 • 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 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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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