Cisco LEAP protocol description		CLEAP = Cisco LEAP			LEAP = Lightweight EAP 				EAP = Extensible Authentication Protocol                                            _________________________________________________________________by:	cameron macnally <descriptive2001@yahoo.com>date:	Thu, 6 Sep 2001 03:39:40 -0700 (PDT)generated from	http://lists.cistron.nl/pipermail/cistron-radius/2001-September/002042.htmlAdam Sulmicki <adam@cfar.umd.edu>	since I could not find any ASCII version I took above html version	and formated it as it is below.Alan DeKok <aland@freeradius.org>       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 CiscoAironet wireless routers etc. It was deduced by analysis of packets passedbetween 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.DefinitionsAP:	Access Point (the Aironet base station)RS:	Radius ServerAPC:	Access Point ChallengeAPR:	Access Point ResponsePC:	Peer ChallengePR:	Peer ResponsePW:	Users plaintext ASCII passwordSK:	Session KeySS:	Shared Secret shared between AP (or upstream proxy) and RSAUTH:	The 16 octet Radius authenticator of the incomintg requestA typical successful LEAP authentication sequence consists of thefollowing Radius packets passed between the wireless access point (AP) andthe Radius server (RS). Each packet contains an EAP-Message as describedbelow. The EAP Message-Authenticator attribute is always present as usualfor EAP.The general description of the protocol is:1. AP->RS: Access-Request/EAP Identity, containing the name of the   user to be authenticated2. RS->AP: Access-Challenge/EAP Request/LEAP, containing a 8 octet random   MSCHAP Peer Challenge (PC) + State3. AP->RS: Access-Request/EAP Response/LEAP, containing the 24 octet MSCHAP   response to the challenge in 2 above (PR) + State4. 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) + State6. 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. Theformat 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 datam octets of binary datan octets, the name of the user being authenticatedSo, for example, packet 2 in the above sequence, containg the access pointchallenge (APC) would contain an EAP-Message Request (Code 0x01) attributesomething 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 iscarried in a cisco-avpair vendor specific radius attribute. The value ofthe attribute is: "leap:session-key=nnnn" where nnnn is 34 octets ofbinary data as described in SK below.Algorithms for each field are described below. Function names are thosefrom RFC 2433. '+' means concatenation. mppe_encrypt is the algorithm forencrypting MS-MPPE-Send-Key as described in RFC 2548.txt, which isalso the same as the 'Tunnel-Password' encryption.PC:	8 octets random binary data sent to APPR:	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 APMPPEHASH: 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 theuser 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     _________________________________________________________________