doc/rfc/leap.txt

   1                         Cisco LEAP protocol description
   2
   3                 CLEAP = Cisco LEAP
   4                         LEAP = Lightweight EAP
   5                                 EAP = Extensible Authentication Protocol
   6
   7      _________________________________________________________________
   8
   9 by:
  10         cameron macnally <descriptive2001@yahoo.com>
  11
  12 date:
  13         Thu, 6 Sep 2001 03:39:40 -0700 (PDT)
  14
  15 generated from
  16         http://lists.cistron.nl/pipermail/cistron-radius/2001-September/002042.html
  17
  18 me:
  19         since I could not find any ASCII version I took above html version
  20         and formated it as it is below. Adam Sulmicki <adam@cfar.umd.edu>
  21
  22      _________________________________________________________________
  23
  24
  25 This document describes the LEAP authentication protocol as used by Cisco
  26 Aironet wireless routers etc. It was deduced by analysis of packets passed
  27 between an Aironet and Cisco ACS.
  28
  29 Relevant RFCs are: 2284, 2716, 2433.
  30
  31 LEAP is a type of Radius EAP protocol (see RFC draft-ietf-radius-eap-05.txt
  32 "Extensible Authentication Protocol Support in RADIUS"). The EAP type for
  33 LEAP is 17 (0x11). It is used to authenticate access by a wireless client
  34 (typically a laptop or pc) to a wireless router, typically a Cisco Aironet
  35 base station.
  36
  37 Definitions
  38 AP:     Access Point (the Aironet base station)
  39 RS:     Radius Server
  40 APC:    Access Point Challenge
  41 APR:    Access Point Response
  42 PC:     Peer Challenge
  43 PR:     Peer Response
  44 PW:     Users plaintext ASCII password
  45 SK:     Session Key
  46 SS:     Shared Secret shared between AP (or upstream proxy) and RS
  47 AUTH:   The 16 octet Radius authenticator of the incomintg request
  48
  49 A typical successful LEAP authentication sequence consists of the
  50 following Radius packets passed between the wireless access point (AP) and
  51 the Radius server (RS). Each packet contains an EAP-Message as described
  52 below. The EAP Message-Authenticator attribute is always present as usual
  53 for EAP.
  54
  55 The general description of the protocol is:
  56
  57 1. AP->RS: Access-Request/EAP Identity, containing the name of the
  58    user to be authenticated
  59
  60 2. RS->AP: Access-Challenge/EAP Request/LEAP, containing a 8 octet random
  61    MSCHAP Peer Challenge (PC) + State
  62
  63 3. AP->RS: Access-Request/EAP Response/LEAP, containing the 24 octet MSCHAP
  64    response to the challenge in 2 above (PR) + State
  65
  66 4. RS->AP: Access-Challenge/EAP Success (with EAP id++)
  67    + State (may be different than the satate send in <2>)
  68
  69 5. AP->RS: Access-Request/EAP Request/LEAP, containing 8 octet Access Point
  70    Challenge (APC) + State
  71
  72 6. RS->AP: Radius Access-Accept/EAP Response/LEAP, containing 24 octet
  73    response to the challenge in 5 above (APR), plus a session key sent
  74    in a cisco-avpair vendor-specific attribute:
  75
  76         Cisco-AVPair = "leap:session-key=..."
  77
  78   where the '...' are 34 binary octets of encrypted data.  This data MUST
  79   follow the '=', and is NOT in ASCII.
  80
  81 LEAP data is carried in an EAP-Message in the Type-Data subfield. The
  82 format of the Type-Data subfield is:
  83
  84 1 octet LEAP protocol version number, currently always 0x01.
  85 1 unused octet, currently always 0x00.
  86 1 octet byte count for the following binary data
  87 m octets of binary data
  88 n octets, the name of the user being authenticated
  89
  90 So, for example, packet 2 in the above sequence, containg the access point
  91 challenge (APC) would contain an EAP-Message Request (Code 0x01) attribute
  92 something like this:
  93
  94     0                   1                   2                   3
  95     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
  96
  97    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  98    |     Code 0x01 |  Identifier   |             Length            |
  99
 100    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 101    |     Type 0x11 |  Version 0x01 | Unused 0x00   | Count 0x08    |
 102
 103    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 104    |               Peer Challenge                                  |
 105
 106    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 107    |               Peer Challenge                                  |
 108
 109    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 110    |   User Name .....
 111    +-+-+-+-+-+-+-+-+-+-+-+-+-+-
 112
 113
 114 Count is 8 octets since the Peer challenge is 8 bytes.
 115 count is 24 for EAP response, with MSCHAP response.
 116 Length is the total number of octets in the EAP-Message.
 117
 118 The Session Key (SK) is sent from RS to AP in the final packet. It is
 119 carried in a cisco-avpair vendor specific radius attribute. The value of
 120 the attribute is: "leap:session-key=nnnn" where nnnn is 34 octets of
 121 binary data as described in SK below.
 122
 123 Algorithms for each field are described below. Function names are those
 124 from RFC 2433. '+' means concatenation. mppe_encrypt is the algorithm for
 125 encrypting MS-MPPE-Send-Key as described in RFC 2548.txt, which is
 126 also the same as the 'Tunnel-Password' encryption.
 127
 128 PC:     8 octets random binary data sent to AP
 129
 130 PR:     24 octets NtChallengeResponse(PC, Unicode(PW))
 131         e.g. AP sends MS-CHAP response to RADIUS server challenge.
 132
 133 APC:    8 octets random binary data sent by the AP
 134
 135 MPPEHASH: 16 octets NtPasswordHash(NtPasswordHash(Unicode(PW))))
 136
 137 APR:    24 octets ChallengeResponse(APC, MPPEHASH)
 138         e.g. RADIUS server sends MS-CHAP response to AP challenge.
 139
 140 SK: 34 octets mppe_encrypt(SS, AUTH,MD5Digest(MPPEHASH + APC + APR + PC + PR))
 141        via rad_tunnel_pwencode()
 142
 143 Notes:
 144 1. Some versions of Cisco ACS incorrectly drop the first 2 bytes of the
 145 user name at the end of the EAP-MEssage in the Peer Challenge packet.
 146
 147 2. If the user name does not exist, the response to packet 1 is a
 148    Radius Access-Reject/EAP Failure
 149
 150      _________________________________________________________________
 151