Cisco LEAP protocol description CLEAP = Cisco LEAP LEAP = Lightweight EAP EAP = Extensible Authentication Protocol _________________________________________________________________ by: cameron macnally date: Thu, 6 Sep 2001 03:39:40 -0700 (PDT) generated from http://lists.cistron.nl/pipermail/cistron-radius/2001-September/002042.html Adam Sulmicki since I could not find any ASCII version I took above html version and formated it as it is below. Alan DeKok The information in the original posting wasn't entirely correct, but it was close. This updated version is correct, and contains additional specifics not found in the original post. _________________________________________________________________ This document describes the LEAP authentication protocol as used by Cisco Aironet wireless routers etc. It was deduced by analysis of packets passed between an Aironet and Cisco ACS. Relevant RFCs are: 2284, 2716, 2433. LEAP is a type of Radius EAP protocol (see RFC draft-ietf-radius-eap-05.txt "Extensible Authentication Protocol Support in RADIUS"). The EAP type for LEAP is 17 (0x11). It is used to authenticate access by a wireless client (typically a laptop or pc) to a wireless router, typically a Cisco Aironet base station. Definitions AP: Access Point (the Aironet base station) RS: Radius Server APC: Access Point Challenge APR: Access Point Response PC: Peer Challenge PR: Peer Response PW: Users plaintext ASCII password SK: Session Key SS: Shared Secret shared between AP (or upstream proxy) and RS AUTH: The 16 octet Radius authenticator of the incomintg request A typical successful LEAP authentication sequence consists of the following Radius packets passed between the wireless access point (AP) and the Radius server (RS). Each packet contains an EAP-Message as described below. The EAP Message-Authenticator attribute is always present as usual for EAP. The general description of the protocol is: 1. AP->RS: Access-Request/EAP Identity, containing the name of the user to be authenticated 2. RS->AP: Access-Challenge/EAP Request/LEAP, containing a 8 octet random MSCHAP Peer Challenge (PC) + State 3. AP->RS: Access-Request/EAP Response/LEAP, containing the 24 octet MSCHAP response to the challenge in 2 above (PR) + State 4. RS->AP: Access-Challenge/EAP Success (with EAP id++) + State (may be different than the satate send in <2>) 5. AP->RS: Access-Request/EAP Request/LEAP, containing 8 octet Access Point Challenge (APC) + State 6. RS->AP: Radius Access-Accept/EAP Response/LEAP, containing 24 octet response to the challenge in 5 above (APR), plus a session key sent in a cisco-avpair vendor-specific attribute: Cisco-AVPair = "leap:session-key=..." where the '...' are 34 binary octets of encrypted data. This data MUST follow the '=', and is NOT in ASCII. LEAP data is carried in an EAP-Message in the Type-Data subfield. The format of the Type-Data subfield is: 1 octet LEAP protocol version number, currently always 0x01. 1 unused octet, currently always 0x00. 1 octet byte count for the following binary data m octets of binary data n octets, the name of the user being authenticated So, for example, packet 2 in the above sequence, containg the access point challenge (APC) would contain an EAP-Message Request (Code 0x01) attribute something like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code 0x01 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type 0x11 | Version 0x01 | Unused 0x00 | Count 0x08 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Name ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+- Count is 8 octets since the Peer challenge is 8 bytes. count is 24 for EAP response, with MSCHAP response. Length is the total number of octets in the EAP-Message. The Session Key (SK) is sent from RS to AP in the final packet. It is carried in a cisco-avpair vendor specific radius attribute. The value of the attribute is: "leap:session-key=nnnn" where nnnn is 34 octets of binary data as described in SK below. Algorithms for each field are described below. Function names are those from RFC 2433. '+' means concatenation. mppe_encrypt is the algorithm for encrypting MS-MPPE-Send-Key as described in RFC 2548.txt, which is also the same as the 'Tunnel-Password' encryption. PC: 8 octets random binary data sent to AP PR: 24 octets NtChallengeResponse(PC, Unicode(PW)) e.g. AP sends MS-CHAP response to RADIUS server challenge. APC: 8 octets random binary data sent by the AP MPPEHASH: 16 octets NtPasswordHash(NtPasswordHash(Unicode(PW)))) APR: 24 octets ChallengeResponse(APC, MPPEHASH) e.g. RADIUS server sends MS-CHAP response to AP challenge. SK: 34 octets mppe_encrypt(SS, AUTH,MD5Digest(MPPEHASH + APC + APR + PC + PR)) via rad_tunnel_pwencode() Notes: 1. Some versions of Cisco ACS incorrectly drop the first 2 bytes of the user name at the end of the EAP-MEssage in the Peer Challenge packet. 2. If the user name does not exist, the response to packet 1 is a Radius Access-Reject/EAP Failure _________________________________________________________________