[openbeosnetteam] Re: general or PPP ideas

> > Why not just provide them as add-ons? After all, they are protocols 
> > in
> > their own rights, especially CHAP, which requires renewal of
> > authentication at various points in the connection. You could turn 
> > them
> > off or on in the settings panel, and specify negotiation preference 
> > in
> > however you configure the ppp server.
> 
> With add-ons you mean kernel modules, don't you?

Assuming it's a kernel-land stack, then yes, just as any other protocol 
would be added.

> I want to do that, but how
> does the server know which users are available and which password 
> they have?

It depends. In the context of a ppp client, they could be attributes of 
the ppp node. For a server, you could have some look-up database whose 
location is defined centrally, perhaps by an attribute.

> Some methods need the raw password from the authenticator and some 
> can tell
> the unencrypted password to the authenticator. If you want to 
> authenticate
> with the OS user DB (like in Unix) it is only possible with PAP 
> because the
> unencrypted password is needed for the user DB which then encrypts 
> the raw
> password and compares it with the encrypted password in the user db. 
> Using
> CHAP is not possible here, for example. Other system could supply the
> unencrypted password to CHAP which then encrypts it for 
> authentication.
> I would like to use userland user-DB-add-ons because it puts less 
> code into
> the kernel. 

You could have a kernel-level protocol module talk to some generalized 
password database.

> But this removes the possibility to make a PPP connection inside
> the kernel. And it adds dependency on a userland application or 
> complicated
> userland API. I would prefer to make it very easy. If the 
> authenticator asks
> the userland DB it must block until each user is authenticated.

Why? It could be asynchronous. 

> > This is negotiated by LCP. If you try to bring up a protocol's NCP 
> > that
> > the ISP doesn't like, it sends back a protocol-reject packet.
> > Essentially, all you need is an ability to close down specific
> > protocols. Again, in the case of servers, there should be a way to
> > specify things, but for the user, little needs to be hardcoded. The
> > server can just never notify protocols it doesn't like of an open 
> > link.
> 
> I would like the client and the server to specify their wishes. :)

I think that, by default, everything should be brought up everywhere. 
You could block it, though.

> > Of course we need settings. The issue is how much need be set.
> 
> Only the basics should be needed, but everything should be possible.
> NCPs should be specified, for example.

Why would you want to specify NCPs? Why not just the protocol?
-Nathan

Other related posts: