RE: pppcn

Jonathan Goodchild writes:
> >From James Carlson:
> 
> > All that needs to be done is guarantee that someone who 
> > doesn't know a shared secret cannot predict the 'random' 
> > portions of the message.  For example, generate a cryptographic 
> > hash based on a shared secret and the challenge used in the 
> > last session (saved in some local storage), and use that 
> > hash as the challenge string.
> 
> Ummmm, this must mean that both peers need to agree on the mechanism for
> generating the next challenge.

Sure.  They also have to agree on the CHAP shared secret and the peer
names.  Quite a bit of agreement is required.

> In which case, for there to be interoperability between peers, this
> mechanism must be a widely understood protocol of some sort, and so I would
> have thought that there would be grounds for publishing it as an RFC.

The protocol on the wire is still CHAP -- it's only a usage
convention, and then only one that is applicable in some restricted
domains (you probably wouldn't want to do this everywhere or perhaps
even for very long into the future as link technologies improve), and
one that poses no interoperability issues at all (if the peer doesn't
understand what you're doing, no harm is done, and normal negotiation
proceeds).

So, I don't quite see it as a problem that requires an RFC, but
(again) if someone really wants to publish it, that's fine by me.  (It
wasn't my original idea anyway ...)

-- 
James Carlson, IP Systems Group                <[email protected]>
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