Client requesting its authentication

Client requesting its authentication

[ben_gal]

Hi.

Is there in pppd an option to specify that we want the peer 
authenticate us using EAP, and to refuse to continue if it does not 
request us ?
I need it to perform an eap-tls authentication.

Re: Client requesting its authentication

[James Carlson]

ben_gal@libero.it writes:
> Is there in pppd an option to specify that we want the peer 
> authenticate us using EAP, and to refuse to continue if it does not 
> request us ?
> I need it to perform an eap-tls authentication.

You'd do it with "refuse-pap refuse-chap refuse-mschap
refuse-mschap-v2".

But, before you go to that trouble, you should know that the default
behavior of pppd is to refuse proposed authentication methods that do
not have corresponding key material with which to authenticate.

In other words, as long as you don't add entries in
/etc/ppp/pap-secrets and /etc/ppp/chap-secrets that match on the
"client" and "server" names, pppd will automatically refuse those
other authentication methods if proposed by the peer.

In general, you shouldn't add and shouldn't have to add pppd options
for most "sensible" behaviors.  When configuring pppd (or, really, any
software), fewer specified options is better.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 11:37:29AM -0500, James Carlson wrote:
> > Is there in pppd an option to specify that we want the peer 
> > authenticate us using EAP, and to refuse to continue if it does not 
> > request us ?
> 
> You'd do it with "refuse-pap refuse-chap refuse-mschap
> refuse-mschap-v2".

Sorry, I made the question in a wrong manner.
I don't want to tell the peer what authentication to do if necessary, but
I want to tell it that I want to authenticate myself (and with EAP), else I 
won't connect.
Is there a way?

Re: Client requesting its authentication

[James Carlson]

ben_gal@libero.it writes:
> > You'd do it with "refuse-pap refuse-chap refuse-mschap
> > refuse-mschap-v2".
> 
> Sorry, I made the question in a wrong manner.
> I don't want to tell the peer what authentication to do if necessary, but
> I want to tell it that I want to authenticate myself (and with EAP), else I 
> won't connect.
> Is there a way?

That's exactly the question I answered -- for the "client" aka
"authenticatee" case.  If the peer (authenticator, server) proposes
some other method, pppd will refuse and suggest EAP instead.

I also noted that you don't need to configure this at all, because
this is already the default for pppd: if the peer requests something
we can't do (because it's not configured), we'll suggest something we
can do.

For the server (authenticator) case, you use the "require-*" options
to tune the behavior.  And as in the client case, there's really no
need to do this, as offering the best usable algorithm first is what
pppd does by default.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005 ben_gal@libero.it wrote:

> On Thu, Feb 24, 2005 at 11:37:29AM -0500, James Carlson wrote:
>>> Is there in pppd an option to specify that we want the peer
>>> authenticate us using EAP, and to refuse to continue if it does not
>>> request us ?
>>
>> You'd do it with "refuse-pap refuse-chap refuse-mschap
>> refuse-mschap-v2".
>
> Sorry, I made the question in a wrong manner.
> I don't want to tell the peer what authentication to do if necessary, but
> I want to tell it that I want to authenticate myself (and with EAP), else I
> won't connect.
> Is there a way?

He understood you perfectly. That is precicely what the refuse-... do,
except that you cannot force the other side to authenticate you . If you
want them to authenticate themselves to you then you must say do.
Ie, authentication is under the control of whoever wants the other side to
be authenticated. Nothing else makes any sense. Of course since eap in some
sense is a bilateral authentication one might argue that y our request is
sensible, but the way to do it is for you to demand eap authentication from
the other side, and to refuse all other types of authentication from the
other side, as Carlson suggested.
Why by the way do you want to force the other side to authenticate you?

Re: Client requesting its authentication

[James Carlson]

Bill Unruh writes:
> He understood you perfectly. That is precicely what the refuse-... do,
> except that you cannot force the other side to authenticate you . If you
> want them to authenticate themselves to you then you must say do.
> Ie, authentication is under the control of whoever wants the other side to
> be authenticated. Nothing else makes any sense. Of course since eap in some
> sense is a bilateral authentication one might argue that y our request is
> sensible, but the way to do it is for you to demand eap authentication from
> the other side, and to refuse all other types of authentication from the
> other side, as Carlson suggested.
> Why by the way do you want to force the other side to authenticate you?

That's a fair question and I'd be interested in the response.

If the problem is that the peer doesn't bother demanding
authentication, and you want the local system to insist that it does,
there's currently no way to tell pppd that such a behavior is desired.
We would have to add an option ("need-peer-auth"?) to say that if the
LCP Authentication option is missing, we need to send an unsolicited
LCP Configure-Nak to request that it use authentication.

However, I have a hard time imagining any case in which doing
something like that is at all valid.  If the peer doesn't ask for
authentication, doesn't that mean it doesn't need you to do it?  If
so, why would you want it?

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 09:43:11AM -0800, Bill Unruh wrote:
> He understood you perfectly. That is precicely what the refuse-... do,
> except that 
> you cannot force the other side to authenticate you .

 This is what I wanted to know.

> If you
> want them to authenticate themselves to you then you must say do.
> Ie, authentication is under the control of whoever wants the other side to
> be authenticated. Nothing else makes any sense. Of course since eap in some
> sense is a bilateral authentication one might argue that y our request is
> sensible, but the way to do it is for you to demand eap authentication from
> the other side, and to refuse all other types of authentication from the
> other side, as Carlson suggested.
> Why by the way do you want to force the other side to authenticate you?

Because I've written a patch to pppd that permits eap-tls authentication.
eap-tls provide mutual authentication, so if you (client) connect to a server,
you want to be sure of its identity, so the authentication can't be
skipped. 

This is the behaviour I were looking for:

using channel 4
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <magic 0x290d2a43> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <asyncmap 0x0> <magic 0x290d2a43> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <auth 0xc227>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x2 <auth 0xc227>]
sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x3 <auth 0xc227>]
sent [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x4 <auth 0xc227>]
sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x5 <auth 0xc227>]
sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x6 <auth 0xc227>]
sent [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x7 <auth 0xc227>]
sent [LCP ConfReq id=0x8 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x8 <auth 0xc227>]
sent [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x9 <auth 0xc227>]
sent [LCP ConfReq id=0xa <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0xa <auth 0xc227>]
sent [LCP ConfReq id=0xb <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
rcvd [LCP TermReq id=0x1 ")\r*C\000<\37777777715t\000\000\002\37777777734"]
sent [LCP TermAck id=0x1]
Modem hangup
Connection terminated.

Is logged between a windows box (client) set to do eap-tls and the 
pppd server.
The server don't want to authenticate the client, but the client want
eap authentication for itself and finally close the negotiation.

Re: Client requesting its authentication

[James Carlson]

ben_gal@libero.it writes:
> Because I've written a patch to pppd that permits eap-tls authentication.
> eap-tls provide mutual authentication, so if you (client) connect to a server,
> you want to be sure of its identity, so the authentication can't be
> skipped. 

My understanding of EAP-TLS is that you really don't want EAP to be
requested by both sides.  Instead, one side should request it, and the
EAP method *itself* provides mutual authentication.

Having both sides request EAP (or any authentication protocol) within
LCP means that both sides are intending to independently authenticate
the other.  In other words, you'd end up with each side independently
and simultaneously sending EAP Request messages and expecting EAP
Response messages in return.

That doesn't sound like what you want.

> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x1 <auth 0xc227>]

Well, we can't do that today.  But since you're writing a patch,
you're free to add it, and if you can justify why it's really the
right thing to do (still unclear to me), it might even get integrated.

> Is logged between a windows box (client) set to do eap-tls and the 
> pppd server.
> The server don't want to authenticate the client, but the client want
> eap authentication for itself and finally close the negotiation.

Wacky.  ;-}

If it wants EAP authentication, why on Earth didn't it just ask for
EAP authentication directly?  What's the point of this little dance?

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 01:15:54PM -0500, James Carlson wrote:
> > Because I've written a patch to pppd that permits eap-tls authentication.
> > eap-tls provide mutual authentication, so if you (client) connect to a server,
> > you want to be sure of its identity, so the authentication can't be
> > skipped. 
> 
> My understanding of EAP-TLS is that you really don't want EAP to be
> requested by both sides. 

Mine is the same :)

> Instead, one side should request it, and the
> EAP method *itself* provides mutual authentication.

Ok.
The server must request it.
But if the server doesn't request authentication?
The client will connect to an untrusted server.
We don't want this to happen.

> Having both sides request EAP (or any authentication protocol) within
> LCP means that both sides are intending to independently authenticate
> the other.  In other words, you'd end up with each side independently
> and simultaneously sending EAP Request messages and expecting EAP
> Response messages in return.
> 
> That doesn't sound like what you want.

No, this isn't. I want the server asking the client EAP.
And the client refuse connection if there's no authentication.

> 
> > sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> > rcvd [LCP ConfNak id=0x1 <auth 0xc227>]
> 
> Well, we can't do that today.  But since you're writing a patch,
> you're free to add it, and if you can justify why it's really the
> right thing to do (still unclear to me), it might even get integrated.

Ok.

> > Is logged between a windows box (client) set to do eap-tls and the 
> > pppd server.
> > The server don't want to authenticate the client, but the client want
> > eap authentication for itself and finally close the negotiation.
> 
> Wacky.  ;-}
> 
> If it wants EAP authentication, why on Earth didn't it just ask for
> EAP authentication directly?  What's the point of this little dance?

Because the server must ask.

Re: Client requesting its authentication

[James Carlson]

ben_gal@libero.it writes:
> > Instead, one side should request it, and the
> > EAP method *itself* provides mutual authentication.
> 
> Ok.
> The server must request it.
> But if the server doesn't request authentication?
> The client will connect to an untrusted server.
> We don't want this to happen.

If it doesn't request it, then, clearly, it doesn't support it or want
to demand it of its peers.  If your local policy rules are such that
you won't talk to someone who doesn't initiate authentication, then I
think the best answer is just to disconnect.

> > > Is logged between a windows box (client) set to do eap-tls and the 
> > > pppd server.
> > > The server don't want to authenticate the client, but the client want
> > > eap authentication for itself and finally close the negotiation.
> > 
> > Wacky.  ;-}
> > 
> > If it wants EAP authentication, why on Earth didn't it just ask for
> > EAP authentication directly?  What's the point of this little dance?
> 
> Because the server must ask.

OK ... but it still seems rather pointless to me.

That said, I see the point now, and, no, there's no option that
currently does that.  You'll need to add one or, better yet, make pppd
just do that by default when EAP TLS client side is configured.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 01:53:20PM -0500, James Carlson wrote:
> If it doesn't request it, then, clearly, it doesn't support it or want
> to demand it of its peers.  If your local policy rules are such that
> you won't talk to someone who doesn't initiate authentication, then I
> think the best answer is just to disconnect.

Right.

> OK ... but it still seems rather pointless to me.
> 
> That said, I see the point now, and, no, there's no option that
> currently does that.  You'll need to add one or, better yet, make pppd
> just do that by default when EAP TLS client side is configured.

Ok. Thanks for the long discussion :)

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005 ben_gal@libero.it wrote:

> On Thu, Feb 24, 2005 at 09:43:11AM -0800, Bill Unruh wrote:
>> He understood you perfectly. That is precicely what the refuse-... do,
>> except that
>> you cannot force the other side to authenticate you .
>
> This is what I wanted to know.
>
>> If you
>> want them to authenticate themselves to you then you must say do.
>> Ie, authentication is under the control of whoever wants the other side to
>> be authenticated. Nothing else makes any sense. Of course since eap in some
>> sense is a bilateral authentication one might argue that y our request is
>> sensible, but the way to do it is for you to demand eap authentication from
>> the other side, and to refuse all other types of authentication from the
>> other side, as Carlson suggested.
>> Why by the way do you want to force the other side to authenticate you?
>
> Because I've written a patch to pppd that permits eap-tls authentication.
> eap-tls provide mutual authentication, so if you (client) connect to a server,
> you want to be sure of its identity, so the authentication can't be
> skipped.

Then demand that they authenticate themselves to you via eap. If that is
what you want then demand it. Why  are you trying to force them into
demanding it from you? " I want you to do something. But I do not want to
ask you to do it, I want to force you to ask me to do it". That is not how
the world works. If you want something, ask for it.


>
> This is the behaviour I were looking for:

Sorry, the behaviour you want is that the two sides never agree on anything
and refuse to talk to each other?

>
> using channel 4
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyS1
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <magic 0x290d2a43> <pcomp> <accomp>]
> sent [LCP ConfAck id=0x0 <asyncmap 0x0> <magic 0x290d2a43> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x1 <auth 0xc227>]
> sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x2 <auth 0xc227>]
> sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x3 <auth 0xc227>]
> sent [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x4 <auth 0xc227>]
> sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x5 <auth 0xc227>]
> sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x6 <auth 0xc227>]
> sent [LCP ConfReq id=0x7 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x7 <auth 0xc227>]
> sent [LCP ConfReq id=0x8 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x8 <auth 0xc227>]
> sent [LCP ConfReq id=0x9 <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0x9 <auth 0xc227>]
> sent [LCP ConfReq id=0xa <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP ConfNak id=0xa <auth 0xc227>]
> sent [LCP ConfReq id=0xb <asyncmap 0x0> <magic 0xb30db629> <pcomp> <accomp>]
> rcvd [LCP TermReq id=0x1 ")\r*C\000<\37777777715t\000\000\002\37777777734"]
> sent [LCP TermAck id=0x1]
> Modem hangup
> Connection terminated.
>
> Is logged between a windows box (client) set to do eap-tls and the
> pppd server.

Well demand that it authenticate itself to you via eap.

> The server don't want to authenticate the client, but the client want
> eap authentication for itself and finally close the negotiation.

That is the other sides perfect right. If someone walked up to you and
demanded that you demand to see his driver's license, don;t you think a
valid reaction on your part is to walk away?

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005 ben_gal@libero.it wrote:

> On Thu, Feb 24, 2005 at 01:15:54PM -0500, James Carlson wrote:
>>> Because I've written a patch to pppd that permits eap-tls authentication.
>>> eap-tls provide mutual authentication, so if you (client) connect to a server,
>>> you want to be sure of its identity, so the authentication can't be
>>> skipped.
>>
>> My understanding of EAP-TLS is that you really don't want EAP to be
>> requested by both sides.
>
> Mine is the same :)
>
>> Instead, one side should request it, and the
>> EAP method *itself* provides mutual authentication.
>
> Ok.
> The server must request it.

There IS NO SERVER. ppp is a point to point protocol in which both sides
have entirely equal status. If you want eap, then ask for it. do not try to
force the other side to ask for it. Both are entirely equal peers.


> But if the server doesn't request authentication?
> The client will connect to an untrusted server.
> We don't want this to happen.

Then ask the other side  to authenticate itself. What is difficult about
that?


>
>> Having both sides request EAP (or any authentication protocol) within
>> LCP means that both sides are intending to independently authenticate
>> the other.  In other words, you'd end up with each side independently
>> and simultaneously sending EAP Request messages and expecting EAP
>> Response messages in return.
>>
>> That doesn't sound like what you want.
>
> No, this isn't. I want the server asking the client EAP.
> And the client refuse connection if there's no authentication.

Why? YOu have this totally weird social model, and are trying to fit the
world into that social model, a world for which it does not fit. 
If you want something, ask. do not sit there waiting and dropping hints for
the other side to ask. This sounds like a bad marriage situation to me.


>
> Because the server must ask.

Why? where does this constraint come from? The wife cannot ask for sex,
only the husband can, and all the wife can do is drop hints? Bad model for
ppp negotiations.

Re: Client requesting its authentication

[James Carlson]

Bill Unruh writes:
> > Ok.
> > The server must request it.
> 
> There IS NO SERVER. ppp is a point to point protocol in which both sides
> have entirely equal status. If you want eap, then ask for it. do not try to
> force the other side to ask for it. Both are entirely equal peers.

More or less.  What he means is that the system that is designated as
the authenticator must ask for it, and he's concerned about what the
authenticatee should do if the authenticator doesn't behave as
expected.  EAP and TLS aren't symmetric that way.

> > But if the server doesn't request authentication?
> > The client will connect to an untrusted server.
> > We don't want this to happen.
> 
> Then ask the other side  to authenticate itself. What is difficult about
> that?

In that case, his side will be the authenticator, and he doesn't want
that to happen.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 01:27:54PM -0800, Bill Unruh wrote:
> Then demand that they authenticate themselves to you via eap. If that is
> what you want then demand it. Why  are you trying to force them into
> demanding it from you? " I want you to do something. But I do not want to
> ask you to do it, I want to force you to ask me to do it". That is not how
> the world works. If you want something, ask for it.

I don't want to *force* the peer to authenticate me.
I want to *hint* him.
If he doesn't want that, I close because that doesn't satisfy me.
This seems not so strange to me.


> >
> >This is the behaviour I were looking for:
> 
> Sorry, the behaviour you want is that the two sides never agree on anything
> and refuse to talk to each other?

Is more desiderable that they don't connect than a client connecting
to an untrusted server without authentication

> Well demand that it authenticate itself to you via eap.

In tls there's a client and a server. Roles cannot be swapped

> 
> That is the other sides perfect right. If someone walked up to you and
> demanded that you demand to see his driver's license, don;t you think a
> valid reaction on your part is to walk away?

Yes. This isn't a problem.
The problem is when I trust him, but we haven't shown driver licenses each
other.

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005, James Carlson wrote:

>
> In that case, his side will be the authenticator, and he doesn't want
> that to happen.

Why?

Especially aqs in eap his side IS an authenticator as well as an
authenticatee. That is precisely what he wants, is for the far side to
authenticate itself to him. He wants to be an authenticator but does not
want to ask to be an authenticator. I cannot see any justification for that
stance. It certainly does not prevent any attack I can think of ( a
sensible attacker would not be as coy as he is).

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005 ben_gal@libero.it wrote:

> On Thu, Feb 24, 2005 at 01:27:54PM -0800, Bill Unruh wrote:
>> Then demand that they authenticate themselves to you via eap. If that is
>> what you want then demand it. Why  are you trying to force them into
>> demanding it from you? " I want you to do something. But I do not want to
>> ask you to do it, I want to force you to ask me to do it". That is not how
>> the world works. If you want something, ask for it.
>
> I don't want to *force* the peer to authenticate me.
> I want to *hint* him.
> If he doesn't want that, I close because that doesn't satisfy me.
> This seems not so strange to me.

Why hint. Just ask. You are demanding that he authenticate himself to you
or you will take your marbles and quit the game, but are unwilling to ask
him to authenticate himself to you. That does seems strange to me.

> In tls there's a client and a server. Roles cannot be swapped

This is NOT true in ppp, which is what you are doing.

>
> Yes. This isn't a problem.
> The problem is when I trust him, but we haven't shown driver licenses each
> other.

If you walk away because he does not show his license to you then you DO
NOT trust him.

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 02:18:44PM -0800, Bill Unruh wrote:
> >In tls there's a client and a server. Roles cannot be swapped
> 
> This is NOT true in ppp, which is what you are doing.

But I cannot do reverse authentication and it can't too.

> >
> >Yes. This isn't a problem.
> >The problem is when I trust him, but we haven't shown driver licenses each
> >other.
> 
> If you walk away because he does not show his license to you then you DO
> NOT trust him.

Eh ? :)

Re: Client requesting its authentication

[James Carlson]

Bill Unruh writes:
> On Thu, 24 Feb 2005, James Carlson wrote:
> 
> >
> > In that case, his side will be the authenticator, and he doesn't want
> > that to happen.
> 
> Why?
> 
> Especially aqs in eap his side IS an authenticator as well as an
> authenticatee.

That's precisely the problem: that's not true.

When you negotiate EAP, the side that sends LCP Configure-Request for
EAP is the authenticator; the other side is the authenticatee.  The
authenticator drives the conversation by sending EAP Request
messages.  The authenticatee merely responds.

Both sides, of course, *may* be either authenticator or authenticatee
or both, provided that the other side plays the opposite role.

In this case, he wants his peer to be an authenticator.  It's supposed
to have the right keys.  His question is what should he do if that
peer *doesn't* behave as an authenticator.

He doesn't have the keys on his side to behave as an authenticator, so
that's out of the question.

> That is precisely what he wants, is for the far side to
> authenticate itself to him.

Not exactly.  He wants the other side to be authenticator, so the keys
all work out right, *and* so that he gets the EAP-TLS mutual
authentication.

He doesn't want to proceed as an authenticatee if the peer doesn't ask
for anything, because he's depending on the mutual-auth built into TLS
for part of his security.

He could send LCP Configure-Nak to suggest EAP, but pppd doesn't do
that currently.  I pointed out that doing so is probably worthless, as
if the peer isn't already asking, it probably doesn't even know how to
do it.  Thus, hanging up the connection is probably the right answer
anyway.

(Which implies that Windows is being a little silly here.)

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005 ben_gal@libero.it wrote:

> On Thu, Feb 24, 2005 at 02:18:44PM -0800, Bill Unruh wrote:
>>> In tls there's a client and a server. Roles cannot be swapped
>>
>> This is NOT true in ppp, which is what you are doing.
>
> But I cannot do reverse authentication and it can't too.

Why not? Just put require-eap into your ppp/options. and you will ask him
for eap. NOw he may refuse, but that is up to him. YOu cannot force someone
else to do something.

>
>>>
>>> Yes. This isn't a problem.
>>> The problem is when I trust him, but we haven't shown driver licenses each
>>> other.
>>
>> If you walk away because he does not show his license to you then you DO
>> NOT trust him.
>
> Eh ? :)

It may be a problem with English. I interpreted your sentence to be 
"the problem is, if I trust him, but we haven't shown...." You might be
saying " the problem is at what time do I trust him-- certainly not if we
have not shown driver ....."

Which did you mean? Do you trust him? If not ask to see his license. Do not
stand there hinting that it would be nice if he volunarily showed you his
license. And then walk away when he does not take the hint.

What prevents you from putting
require-eap
into your options file which will result in your eap asking him to
authenticate himself to you and you to him with eap?

>

-- 
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: Client requesting its authentication

[Bill Unruh]

On Thu, 24 Feb 2005, James Carlson wrote:

>
> That's precisely the problem: that's not true.
>
> When you negotiate EAP, the side that sends LCP Configure-Request for
> EAP is the authenticator; the other side is the authenticatee.  The
> authenticator drives the conversation by sending EAP Request
> messages.  The authenticatee merely responds.

Perhaps, but what he wants is for the far side to authenticate itself to
him. Period. How it happens is irrelevant. Now if the far side refuses.
then he has to decide what to do. It is up to him. He cannot force the
other side to do anything. His only option is walking away or not.

>
> Both sides, of course, *may* be either authenticator or authenticatee
> or both, provided that the other side plays the opposite role.
>
> In this case, he wants his peer to be an authenticator.  It's supposed
> to have the right keys.  His question is what should he do if that
> peer *doesn't* behave as an authenticator.
>

He decides whether or not to walk away.


> He doesn't have the keys on his side to behave as an authenticator, so
> that's out of the question.

That cannot be right, since he is also authenticating the far side. Ie, he
MUST have enough info to do that.

>
>> That is precisely what he wants, is for the far side to
>> authenticate itself to him.
>
> Not exactly.  He wants the other side to be authenticator, so the keys
> all work out right, *and* so that he gets the EAP-TLS mutual
> authentication.
>
> He doesn't want to proceed as an authenticatee if the peer doesn't ask
> for anything, because he's depending on the mutual-auth built into TLS
> for part of his security.
>
> He could send LCP Configure-Nak to suggest EAP, but pppd doesn't do
> that currently.  I pointed out that doing so is probably worthless, as
> if the peer isn't already asking, it probably doesn't even know how to
> do it.  Thus, hanging up the connection is probably the right answer
> anyway.

ppp does ask for pap or chap. (Ie if the far side asks for pap, and youcan
offer chap, it does do a confnak). But as you say, since eap is the
strongest authentication model, it should be offered first anyway if
available. Of course as we both know, implimentations of ppp shall we say
vary widely.


>
> (Which implies that Windows is being a little silly here.)

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 02:38:09PM -0800, Bill Unruh wrote:
> >But I cannot do reverse authentication and it can't too.
> 
> Why not? Just put require-eap into your ppp/options. and you will ask him
> for eap. 

I can't require an authentication that I will not be able to do.
In the other email Carlson explain well why.

> 
> >
> >>>
> >>>Yes. This isn't a problem.
> >>>The problem is when I trust him, but we haven't shown driver licenses 
> >>>each
> >>>other.
> >>
> >>If you walk away because he does not show his license to you then you DO
> >>NOT trust him.
> >
> >Eh ? :)
> 
> It may be a problem with English. I interpreted your sentence to be 
> "the problem is, if I trust him, but we haven't shown...." You might be
> saying " the problem is at what time do I trust him-- certainly not if we
> have not shown driver ....."

I mean:

if I trust him, but we have not authenticated each other,
then it's a problem

> What prevents you from putting
> require-eap
> into your options file which will result in your eap asking him to
> authenticate himself to you and you to him with eap?

I have explained that. 
The peer must act as a server.
I can't.

Re: Client requesting its authentication

[Bill Unruh]

>
> if I trust him, but we have not authenticated each other,
> then it's a problem

If you trust him, then you trust him. If you require authentication then
you do not trust him.

>
>> What prevents you from putting
>> require-eap
>> into your options file which will result in your eap asking him to
>> authenticate himself to you and you to him with eap?
>
> I have explained that.
> The peer must act as a server.
> I can't.
Why not?

Yes, you can. just set up eap on your system and act like the server. 
Now the far side may reject it, and that is up to them. So talk to them.
Ask them to offer you eap, if that is what you want. Ask them to agree to
be an eap client if that is what you want. But at present you are trying to
force the far side to do something it does not want to do. There is nothing

Re: Client requesting its authentication

[James Carlson]

Bill Unruh writes:
> > When you negotiate EAP, the side that sends LCP Configure-Request for
> > EAP is the authenticator; the other side is the authenticatee.  The
> > authenticator drives the conversation by sending EAP Request
> > messages.  The authenticatee merely responds.
> 
> Perhaps, but what he wants is for the far side to authenticate itself to
> him. Period. How it happens is irrelevant. Now if the far side refuses.
> then he has to decide what to do. It is up to him. He cannot force the
> other side to do anything. His only option is walking away or not.

How the authentication happens *is* relevant.

First of all, EAP TLS is not symmetric.  The two sides have different
data.  (Think of PAP with the "papcrypt" option; you couldn't reverse
roles there.)

Secondly, he wants to see EAP TLS happen.  Sure, he could challenge
the peer with some other authentication protocol (say, CHAP), but he's
decided that (for whatever reason) his security requirements include
having TLS in the picture.  So just switching to a different protocol
is unacceptable as well.

> > In this case, he wants his peer to be an authenticator.  It's supposed
> > to have the right keys.  His question is what should he do if that
> > peer *doesn't* behave as an authenticator.
> >
> 
> He decides whether or not to walk away.

Exactly.  That's what I said.

The interesting wrinkle is that he *could* use an unsolicited LCP
Configure-Nak to try to prod the peer into doing what he wants.
Windows apparently does this.  I don't think it's a worthwhile
exercise, but it's certainly doable.

> > He doesn't have the keys on his side to behave as an authenticator, so
> > that's out of the question.
> 
> That cannot be right, since he is also authenticating the far side. Ie, he
> MUST have enough info to do that.

The protocol isn't symmetric.  The authentication is mutual, but
different information is used.  You can't just reverse the roles.

-- 
James Carlson                                 <carlsonj@workingcode.com>

Re: Client requesting its authentication

[ben_gal]

On Thu, Feb 24, 2005 at 01:53:20PM -0500, James Carlson wrote:
> That said, I see the point now, and, no, there's no option that
> currently does that.  You'll need to add one or, better yet, make pppd
> just do that by default when EAP TLS client side is configured.


I resolved with this code in auth.c , link_established():


    if(need_peer_eap && !ao->neg_eap) {
       warn("eap required to authenticate us but no suitable secrets");
        lcp_close(unit, "couldn't negotiate eap");
        status = EXIT_AUTH_TOPEER_FAILED;
        return;
    }

    if (need_peer_eap && !ho->neg_eap){
        warn("peer doesn't want to authenticate us with eap");
        lcp_close(unit, "couldn't negotiate eap");
        status = EXIT_PEER_AUTH_FAILED;
        return;
    }


So if the need_peer_eap option is used the eap authentication can't
be skipped.
I don't use LCP Configure-Nak because, as you noticed, if the peer
doesn't ask eap, probably won't accept the suggestion.

Hi.