CHAP Secret - non-printable charaters - PPP

This is a discussion on CHAP Secret - non-printable charaters - PPP ; Hi, The RFC 1334 Implementation note mentions that "CHAP requires the passwords be in plaintext...". 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: CHAP Secret - non-printable charaters

  1. CHAP Secret - non-printable charaters

    Hi,

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

    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.

    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.

    I tried embedding the password into the file and giving the file as
    input to the pppSecretAdd method (VxWroks allows this kind of
    indirection), still it doesn't work when I have a newline character or
    backspace as part of the secret.

    Is there any way out for me with this limitation? I am surprised that
    none of the products which use VxWorks PPP library so far, didn't hit
    this limitation.

    Any kind of help is much appriciated.

    ~Hari


  2. Re: CHAP Secret - non-printable charaters

    "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

+ Reply to Thread