"HT" writes:
> The RFC 1334 Implementation note mentions that "CHAP requires the
> passwords be in plaintext...".

RFC 1334 is obsolete for CHAP; use 1994 instead.

Right; that means they're not encrypted. It doesn't mean that they're
any sort of printable text.

> I have a requirement where the password is generated randomly and given
> to the PPP Server (running on VxWorks system) and the client by some
> secure means.

That's fine.

> The PPPLib in VxWorks provides pppSecretAdd function to add secrets to
> the data base and it takes only "char *" as input. Which means all
> special characters like Null, \n etc, which are part of the original
> secret, will not get entered correctly into the secrets database and
> the CHAP-MD5 authentication fails when the client dials in.

That's just a broken library. Complain to the vendor. The 'secret'
should be an uninterpreted sequence of bytes.

(Why a library using an interface with just "char *" -- and no length
-- would necessarily do anything more than look for the terminating
ASCII NUL byte is beyond me. Are you _sure_ it tries to interpret
"\n" as magical?)

Note that many implementations make essentially the same assumptions,
just for ease-of-use. Technically, there's no limitation on the
contents of the shared secret, as I mentioned above, but I think
you'll find in practice that many implementations won't swallow
special characters -- in particular, hex 00.

There's no loss of generality or security (as far as I know) in
converting the raw byte sequence into either a sequence of hex digits
or a base-64 encoded string, so long as both sides have the same
shared secret. (Surely, there's no loss in entropy by doing this
encoding, and as I understand the mechanism, it's entropy that's the
key criterion for goodness in the shared secret.)

If it were my project, I'd convert the secret to some more easily
handled form rather than fighting common practice. Being "right" per
the RFCs is not much help if you can't get your software to work.
(It's sort of like being "right" in crossing the street in front of
traffic.)

--
James Carlson, KISS Network
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677