Subject: 16 byte CHAP Challenge length REQUIRED?

From: "John Martz" <[email-masked]>
Date: Thu, 7 Dec 2000 10:31:15 -0500

Good folk of the PPP mailing list:

I have noticed in the past that quite often the CHAP challenge sent from 
other PPP implementations is always exactly 16 bytes (128 bits) in length. 
 On the other hand, our implementation generates a CHAP challenge with a 
length which varies between 16 and 64 bytes. The length is picked "at 
random" each time a challenge is generated.

I never thought much about this implementation difference before since my 
understanding of the RFC allows either method. But it appears that the 
Acess-Request packets we send to a Microsoft Windows 2000 Server Radius 
implementation succeed only when the length of the CHAP challenge provided 
in an Access-Request is exactly 16 bytes long. 

It is VERY hard to believe that Win2K RADIUS really only supports 16 byte 
CHAP challenges. So  we're trying to figure out what we might doing wrong. 
Perhaps we made an error when setting up the Win2K RADIUS server? Or 
perhaps there is something wrong with the requests our NAS is sending to 
Win2K RADIUS?  But if we are in error, we have not been able to determine 
what we are doing wrong. Also, our RADIUS authentication requests which 
specify a non-16 byte CHAP Challenge are accepted when we use a different 
(non-Win2K) RADIUS server.

I'm not aware of any restriction in the Radius RFC on the length of a CHAP 
challenge provided by a NAS beyond saying that 16 bytes is "preferable". 
(BTW, can anyone tell me/speculate on why a 128 bit CHAP challenge length 
is viewed as preferable?) 

I was hoping I might be able to get confirmation one way or another from 
this list. I would appreciate it if anyone else who has tried sending an 
Access-Request to a Win2K RADIUS with a non-16 byte CHAP challenge length 
could let me know if it worked for them. 

-john martz, 8-852-5539,  [email-masked]
IBM AS/400 TCP/IP PPP development (and stuff)

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Dec 2000 10:39:40 -0500 (EST)

> random" each time a challenge is generated.

That's a reasonable thing to do.

> in an Access-Request is exactly 16 bytes long. 

Well, an obvious issue is that there's a bit of RADIUS oddity about a
Challenge value of exactly 16 octets.  See RFC 2865 section 2.2 -- if
the challenge is exactly 16 octets, then it "can be" placed in the
Request Authenticator field of the Access-Request packet, rather than
in a separate CHAP-Challenge attribute.

Perhaps either the RADIUS server or the NAS has bugs in dealing with
the CHAP-Challenge attribute.

> is viewed as preferable?) 

You don't need the extra attribute if it's exactly that length.

(Perhaps this would be more appropriate in the nasreq wg ... ?)

-- 
James Carlson                                  <[email-masked]>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: Barney Wolff <[email-masked]>
Date: Thu, 7 Dec 2000 10:44:34 -0500

By RFC, there is no such requirement.  But as a pragmatic issue,
there is no value in a longer challenge, since the computed hash
will also be 16 bytes.  The chap-challenge attribute was added
to RADIUS late in its development - originally the challenge was
simply put into the Authenticator, which is fixed at 16 bytes.
Some early RADIUS servers don't support the attribute - my
RADIUS proxy implementation moves the challenge to the authenticator
if it is 16 bytes, to aid interoperability.  It is a suprise to
find a recent server implementation that does not support it -
perhaps the MS-CHAP challenge is always 16 - but that's pure
speculation.

With no particular value to a longer challenge, and danger of
duplication in a shorter one, why not just give in and use 16?

Barney Wolff

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Dec 2000 10:57:28 -0500 (EST)

Barney Wolff writes:
[...]
> perhaps the MS-CHAP challenge is always 16 - but that's pure

Good point.  MS-CHAPv1 and v2 both force the challenge to exactly 16
octets by the use of a decidedly un-PPP-like fixed-size data
structure.  That would be a good explanation.

> duplication in a shorter one, why not just give in and use 16?

Well, for one thing, RFCs 1994 and 2865 are on Standards Track, and
both permit variable-length challenges.  The only fixed-size challenge
ones are RFCs 2433 and 2759, both of which are Informational.

(One might also argue that intentionally causing failures in
non-compliant implementations is a worthwhile value in using a longer
challenge.  ;-})

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Dec 2000 11:01:05 -0500 (EST)

> structure.  That would be a good explanation.

Um.  8 octets for v1 and 16 for v2, of course.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 7 Dec 2000 20:10:41 -0800

> structure.  That would be a good explanation.

Hmm.  'Decidedly un-PPP-like'?  From RFC 2759:

3.  Challenge Packet

   The MS-CHAP-V2 Challenge packet is identical in format to the
   standard CHAP Challenge packet.

   MS-CHAP-V2 authenticators send an 16-octet challenge Value field.
   Peers need not duplicate Microsoft's algorithm for selecting the 16-
   octet value, but the standard guidelines on randomness [1,2,7] SHOULD
   be observed.

   Microsoft authenticators do not currently provide information in the
   Name field.  This may change in the future.

BTW, I seem to recall that the MSFT RADIUS client never puts the challenge
(CHAP or MS-CHAP) in the Request-Authenticator, but uses the CHAP-Challenge
or MS-CHAP-Challenge attributes, respectively.  Sounds like a bug in the
RADIUS server to me...

> non-compliant implementations is a worthwhile value in using a longer

How true.

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Dec 2000 07:44:47 -0500 (EST)

> Hmm.  'Decidedly un-PPP-like'?  From RFC 2759:

The MS-CHAPv2 Challenge packet does have its un-PPP characteristics.
For example, section 3 of RFC 2759 indicates that the Value field is
16 octets.

In contrast, RFC 1994 defines a CHAP Challenge Value to be a
variable-length field:

   Value

      The Value field is one or more octets.  The most significant octet
      is transmitted first.

      The Challenge Value is a variable stream of octets.  The

The MS-CHAPv2 Response is even stranger and more un-PPP-like:

   16 octets: Peer-Challenge
    8 octets: Reserved, must be zero
   24 octets: NT-Response
    1 octet : Flags

> or MS-CHAP-Challenge attributes, respectively.  Sounds like a bug in the

Entirely possible.  That part was just a guess based on the original
poster's observation that 16 octets seems to be a magic number.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 8 Dec 2000 10:05:07 -0800

>    MS-CHAP-V2 authenticators send an 16-octet challenge Value field.

True, but I read (and wrote) that more as a statement of implementation fact
then a prescription; since the format of the MS-CHAP-Challenge packet is
stolen by reference from RFC 1994, the Value is variable length by
definition.  It just happens that all (Microsoft) MS-CHAP v2 authenticators
send 16 octets.  Looking at it now, that could be a little clearer but it
probably doesn't matter in practice.