326 |
#endif |
#endif |
327 |
ppp_settings.refuse_chap = 1; |
ppp_settings.refuse_chap = 1; |
328 |
break; |
break; |
329 |
|
case PPPAUTHTYPE_ANY: |
330 |
|
/* Warning: Using PPPAUTHTYPE_ANY might have security consequences. |
331 |
|
* RFC 1994 says: |
332 |
|
* |
333 |
|
* In practice, within or associated with each PPP server, there is a |
334 |
|
* database which associates "user" names with authentication |
335 |
|
* information ("secrets"). It is not anticipated that a particular |
336 |
|
* named user would be authenticated by multiple methods. This would |
337 |
|
* make the user vulnerable to attacks which negotiate the least secure |
338 |
|
* method from among a set (such as PAP rather than CHAP). If the same |
339 |
|
* secret was used, PAP would reveal the secret to be used later with |
340 |
|
* CHAP. |
341 |
|
* |
342 |
|
* Instead, for each user name there should be an indication of exactly |
343 |
|
* one method used to authenticate that user name. If a user needs to |
344 |
|
* make use of different authentication methods under different |
345 |
|
* circumstances, then distinct user names SHOULD be employed, each of |
346 |
|
* which identifies exactly one authentication method. |
347 |
|
* |
348 |
|
*/ |
349 |
|
ppp_settings.refuse_pap = 0; |
350 |
|
ppp_settings.refuse_chap = 0; |
351 |
|
break; |
352 |
case PPPAUTHTYPE_PAP: |
case PPPAUTHTYPE_PAP: |
353 |
ppp_settings.refuse_pap = 0; |
ppp_settings.refuse_pap = 0; |
354 |
ppp_settings.refuse_chap = 1; |
ppp_settings.refuse_chap = 1; |