Subject: [eap] Issue 204: Peer-to-peer operation

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Nov 2003 00:31:10 -0800 (PST)

Issue 204: Peer-to-peer operation
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 11/24/2003
Reference:
http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf
(See disposition of comment 15)
Document:  SM-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current
EAP SMs do not fully support peer-to-peer operation.

The current EAP Peer SM does not provide a mechanism for the EAP method to
signal to EAP and the lower layer that mutual authentication has been
achieved.

In addition, the EAP authenticator SM does not provide a mechanism for the
EAP layer to indicate to the lower layer that a protected result
indication has been received from the peer, indicating that the peer has
authenticated the authenticator.

Similarly, the EAP Peer SM does not provide a mechanism for the EAP layer
to indicate to the lower layer that a protected result indication has been
received from the authenticator, indicating that the Authenticator has
authenticated the peer.

As a result of these missing indications, it is not possible for EAP to
provide for mutual opening of the 802.1X controlled ports for use in
peer-to-peer operation, even where a method providing for protected result
indications is in use.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 25 Nov 2003 09:02:47 -0500 (EST)

> EAP SMs do not fully support peer-to-peer operation.

I am not completely convinced of this. It seems to me what you are asking
for here is for EAP to provide two signals indicating the success of
authentication in each direction. This is not how I read the model of
2284bis. I would argue that the use of a method providing mutual
authentication still requires EAP to provide only one answer to
the conversation. It is possible to require mutual authentication before
Success and even to guarantee that answer with protection, but I do not
see a reason for the lower layer to get an explicit "mutual
authentication" signal. If mutual authentication is required and it was
not obtained then success (the signal, not the packet) will never follow
for a properly configured peer.

> signal to EAP and the lower layer that mutual authentication has been
I disagree. If you require mutual authentication then EAP Success is this
indication.

> authenticated the authenticator.
hmm, this one is slightly more interesting, but I have no idea how the
backend would ever alert the passthrough of this. Still, I think it is
possible to say that if mutual authentication is required and not
achieved then the decision will be fail.

> received from the authenticator, indicating that the Authenticator has
I disagree with  this too. 2284bis states that the only thing which can
follow a protected success/failure is an unprotected version of the same.
The EAP Success indication is therefore sufficient to indicated succes. If
a protected indication is required the peer policy should reflect this and
the SUCCESS state will not be reached until it comes.

I disagree that peer-to-peer is not supported. I would agree that the
specific interface is not provided for two signals, but I would like to
understand better why those signals are needed. Also, a suggestion for
where these signals would go and who sets them might help me understand
this issue better.

Thanks,
nick

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Nov 2003 07:16:30 -0800 (PST)

> for a properly configured peer.

That makes sense to me, because the peer would not accept the access
offered by the authenticator otherwise.  However, the response to IEEE
802.1X D7.1 comment 15 suggests that something further is needed. I'm not clear
what this is, but I'm suggesting that we need to be clear on why this is
not required (and note this explicitly in the SM document).

> I disagree. If you require mutual authentication then EAP Success is this

The resolution of IEEE 802.1X D7.l comment 15 states explicitly that this
indication is insufficient for peer-to-peer operation, potentially because
of the issue with protected result indications below.

> achieved then the decision will be fail.

I think the issue is the following:

a. The authenticator figures out whether it wants to offer access to the
peer or not.  In the case of pass-through this is communicated in the
Access-Accept.

b. The authenticator communicates it desire to offer access to the peer.
This occurs via a protected result indication.

c. The peer figures out whether it wants to accept that access. This is
communicated to the authenticator via a protected result indication
and communicated to the peer lower layer via eapSuccess.

c. This creates a situation where the peer has full knowledge of each
side's decision (peer knows the authenticator is offering access, and that
it wants to use the access), but the authenticator may not (authenticator
knows that it wants to offer access, but in the case of pass-through
operation it may not know if the peer has accepted it).

To fix this, the authenticator SM could have a variable that says that
the peer has provided a protected result indication to it, indicating that
it will accept the offered access.  In terms of AAA, this
could result in a new attribute indicating "peer-to-peer auth achieved" or
something of that nature, so that another EAP authentication need not be
rerun in the opposite direction.

> where these signals would go and who sets them might help me understand

Have a look at the IEEE 802.1X D7.1 resolutions to comment 15.  They're
available here:

Username: p8021
password: go_wildcats

---

From: Nick Petroni <[email-masked]>
Date: Tue, 25 Nov 2003 10:21:15 -0500 (EST)

Preface: I am not a AAA expert so correct me where I am wrong.

comments inline.

> peer or not.  In the case of pass-through this is communicated in the
This does not come until the conversation is over, no? That is, all
protected messages will be finished before the Access-Accept, right?

> This occurs via a protected result indication.
yes, but this would be in an access-challenge, right? Protected success
cannot be the last message in the protocol since a response is required
from the peer even if it's just "ACK".

> and communicated to the peer lower layer via eapSuccess.
these do not happen in the same step. the result will come as the final
EAP response, which will be communicated as an Access-request. The peer
will then wait for an unprotected success or timeout and go to SUCCESS.

> operation it may not know if the peer has accepted it).
not in the case you describe above where a protected response is given.
this will make it back before the Accept-success is ever sent (at least
according to my understanding of RADIUS/EAP interraction).

> rerun in the opposite direction.
I am not a AAA expert so I do not completely understand what you mean by
this, but it seems plausible that such an indication could be set in the
current system.

> Have a look at the IEEE 802.1X D7.1 resolutions to comment 15.  They're

I have read it and did so before my last post, but I find the discussion
vague and unclear. Perhaps someone who participated in that comment
resolution can elighten me? I will re-read it in case I am just slow this
morning ;).

thanks,
nick

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Nov 2003 07:47:57 -0800 (PST)

> protected messages will be finished before the Access-Accept, right?

Right.  The Access-Accept lets the pass-through know that it is to offer
access.

> from the peer even if it's just "ACK".

Yes. So the peer knows that it will be offered access by the
authenticator.  I say "will be" because the pass-through authenticator
does not know this yet, because it hasn't gotten the Access-Accept. And
until it gets the Access-Accept it can't actually provide the access.

> will then wait for an unprotected success or timeout and go to SUCCESS.

Yes. The peer communicates to the backend authentication that it will
accept the access, but the pass-through authenticator does not know this.
I think the point of this is that as a result, it might have to rerun an
EAP authentication in the other direction in order to be sure that it has
been granted access to the peer.

> according to my understanding of RADIUS/EAP interraction).

This is true in non-passthrough operation.  But in pass-through, the
pass-through authenticator doesn't know that the peer is going to offer
access, because it didn't snoop on the result indication sent by the peer.
So the backend authenticator knows, but the authenticator doesn't.

> this, but it seems plausible that such an indication could be set in the

The goal is to bring the pass-through authenticator and backend
authenticator to the same level of knowledge and make it unnecessary to
rerun EAP in the other direction.

> resolution can elighten me? I will re-read it in case I am just slow this

Yes, I also found it vague (I wasn't at the IEEE 802 meeting, since it
conflicted with IETF).  Perhaps someone who was there can enlighten us
both :)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 25 Nov 2003 15:38:13 -0500 (EST)

> until it gets the Access-Accept it can't actually provide the access.
yes, but until it gets the Access-Accept it won't send the EAP Success
either so the peer won't try to have access. In this case all is still
well.

Do we agree there is no problem on the peer side? If so, let's turn to the
authenticator...

> been granted access to the peer.
It seems to me what you are saying is that even after recieving and
Accept-Accept, the passthrough does not know it is allowed to have access
even though it is allowed.

There are two possible solutions I see-
1. make Access-Accept mean that BOTH things are ok and that mutual auth
is known to have succeeded or
2. make Access-Accept strictly mean the Peer is to be given access, and
make some other AAA signal/message provide the other information.

If mutual auth is required, the server can tie the auth directly to the EAP
aaaEapSuccess signal. That is, both must be authenticated for
aaaEapSuccess to be true. This
only works for case 1 above, as the AAA layer can't separate these two if
it is only given binary input. I believe THIS is the missing variable you
describe?

I am really having trouble with the model for why the passthrough needs
this information. when using a peer and a passthrough authenticator, it's
tough for me to see the true peer-to-peer relationship we are describing
in any real-world scenario. That being said, this does not mean we
shouldn't handle the situation. My understanding of all passthrough
implemenations is that if there was to be mutual authentication, but the
peer failed to authenticate the authenticator the peer will just go away
(or try again) anyway.

Additionally, I understand the argument that we want
passthrough and standalone to have the same semantics, but I think even
in the peer and standalone statemachines it is policy that is tying
together the two authentication decisions into a single signal. The method
should be set to only succeed in the case of mutual authentication if
mutual auth is required.

> conflicted with IETF).  Perhaps someone who was there can enlighten us
I look forward to it :).

My current position is that I don't see why you need two answers. If you
know you are using a method with mutual authentication, then you should be
able to tie the outcome of that method to a two-way relationship.

comments welcome.

nick

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Nov 2003 19:26:34 -0800 (PST)

> Do we agree there is no problem on the peer side? If so, let's turn to the

Yes, I agree with this.  Not sure about the IEEE 802.1aa folks.  Can
anyone who was there fill us in?

> It seems to me what you are saying is that even after receiving an

Yes, the pass-through knows it will provide access to the peer, but
doesn't know whether the peer will accept the access.  Note that if the
authenticator was not a pass-through, then it would know, because it would
have received the result indication from the peer.

> is known to have succeeded or

I don't think we can change the meaning of Access-Accept at this point.

> make some other AAA signal/message provide the other information.

This one could work.  For example, we could add a "P2P complete" attribute
to tell the pass-through that the peer has sent a successful result
indication.

> it is only given binary input. I believe THIS is the missing variable you

I think another variable is needed on the authenticator SM to indicate
that a result indication has been received from the peer.

> in any real-world scenario.

The scenario that IEEE 802.1af has been looking are bridges talking to one
another.  I think that the IEEE 802.11 adhoc scenario may also be
affected. The way to think about this is "can the two sides confirm that
both controlled ports are passing packets, so that another EAP
authentication will not have to be run in both directions".  If the answer
is no, then you need to do another authentication, which is wasteful.

> That being said, this does not mean we
> implementations is that if there was to be mutual authentication, but
> the peer failed to authenticate the authenticator the peer will just go
> away (or try again) anyway.

Yes.

> should be set to only succeed in the case of mutual authentication if

I think there may be subtle distinction being made between mutual auth
(where the authenticator might not know whether the peer is going to
accept the access it granted), and protected result indications, where the
authenticator would know the peer decision, absent the pass-through issues
we just talked about.

> able to tie the outcome of that method to a two-way relationship.

As mentioned above, I think it's about both sides being able to confirm
that they are willing to talk at L3, not just for the authenticator to
confirm its willingness to offer access to the peer.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Nov 2003 12:17:38 +0200

Interesting discussion! When we come to a conclusion, we
should document the result in the state machine
spec just to avoid people asking about it later.

A couple of points:

   o  Assuming 802.11i, wouldn't mutual authentication be
      required in any case, so in theory 802.11i equipment
      could assume Access-Accept = mutual authentication?

   o  But in general, I agree that if methods could provide
      information to other layers about the type of
      authentication they performed, this would be useful.

   o  If we do provide such information over an API, we
      also need new AAA attributes as Bernard pointed out.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 08:06:55 -0800 (PST)

>       could assume Access-Accept = mutual authentication?

I think the issue may in part be that mutual auth != confirmed result
indications.

>       also need new AAA attributes as Bernard pointed out.

Yes, I think that may be required.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 26 Nov 2003 08:44:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Wednesday, November 26, 2003 8:07 AM
> To: Jari Arkko
> Cc: Nick Petroni; [email-masked]
> Subject: Re: [eap] Issue 204: Peer-to-peer operation
> 
> 
> > Interesting discussion! When we come to a conclusion, we should 
> > document the result in the state machine spec just to avoid people 
> > asking about it later.
> >
> > A couple of points:
> >
> I think the issue may in part be that mutual auth != 
> confirmed result indications.

[Joe] Yes this seems to be the issue, but I'm still not sure what the
value is in confirmed result indicators or why it has to be done in EAP
and not the layer calling EAP.  

> Yes, I think that may be required. 

[Joe] If these attributes are not present do you deny access or is this
a local policy decision on the NAS?   Shouldn't this be centralized with
the rest of the access policy in AAA?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 09:12:46 -0800 (PST)

> the rest of the access policy in AAA?

I think this is more about whether it is necessary to rerun EAP in the
other direction.  The authenticator will still provide access either way.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 26 Nov 2003 09:13:23 -0800

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2003 9:13 AM
> To: Joseph Salowey
> Cc: 'Jari Arkko'; 'Nick Petroni'; [email-masked]
> Subject: RE: [eap] Issue 204: Peer-to-peer operation
> 
> 
> I think this is more about whether it is necessary to rerun 
> EAP in the other direction.  The authenticator will still 
> provide access either way.
> 
[Joe] OK, sorry to be playing catch up, so the possibility is that the
Peer has not had its policy satisfied so it will not open its port, but
the authenticator may not have any way to know this since it may have
considered its policy complete.  It would seem that in this case the
peer would then want to reverse roles and authenticate the previous
authenticator.  Can't this be signaled in 802.1x?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 09:55:35 -0800 (PST)

> authenticator.  Can't this be signaled in 802.1x?

The authenticator originates EAP authentication and then it offers access
to the peer, or it doesn't.  It might like to send some packets to the
peer, in which case it is interested in whether the peer has accepted the
access it offered, but it may not know that.  If so, then it could send an
EAP-Start to the peer, to signal the peer that it would like to start an
authentication in the other direction.  So it's not a big deal, really.

The point (for RFC 2284bis at least) is just to describe the situation in
Section 2.4, Peer-to-peer operation.  I think that some changes may be
required in the EAP SM to allow the signals to be passed to the lower
layer though.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 26 Nov 2003 10:00:46 -0800

> Sent: Wednesday, November 26, 2003 9:56 AM
> To: Joseph Salowey
> Cc: [email-masked]
> > Peer has not had its policy satisfied so it will not open its port, 
> > but the authenticator may not have any way to know this 
> since it may 
> > have considered its policy complete.  It would seem that in 
> this case 
> > the peer would then want to reverse roles and authenticate the 
> > previous authenticator.  Can't this be signaled in 802.1x?
> 
> The authenticator originates EAP authentication and then it 
> offers access to the peer, or it doesn't.  It might like to 
> send some packets to the peer, in which case it is interested 
> in whether the peer has accepted the access it offered, but 
> it may not know that.  

[Joe] So the protected result is not just signaling that the
authentication was successful, but also that the peer has authorized the
opening of its port. If the Peer actually wanted to do bi-drection
authenticaiton perhaps using a different EAP method then it wouldn't
send a protected result indication of succss even if the first method
succeeded?

> If so, then it could send an EAP-Start 
> to the peer, to signal the peer that it would like to start 
> an authentication in the other direction.  So it's not a big 
> deal, really.
> 
[Joe] Couldn't the peer to signal to the authenticator to start
authentication in the other direction since it is the peer that knows if
it has opened.  If it can't then this seems like a .1x problem. If it
can then I don't think it is a big deal.  

> The point (for RFC 2284bis at least) is just to describe the 
> situation in Section 2.4, Peer-to-peer operation.  I think 
> that some changes may be required in the EAP SM to allow the 
> signals to be passed to the lower layer though.

[Joe] Yes, I think we need to revisit the method interfaces in the state
machines (for issue 203 as well).

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Nov 2003 10:51:56 -0800 (PST)

> send a protected result indication of succss even if the first method

I think those are orthogonal issues.  The peer would send a protected
result indication for the initial method.  The authenticator would then
assume that the peer was happy so that it would not ask the to
authenticate to the peer (e.g. by sending an EAPOL-Start).  But the peer
could always send an EAP-Request if it wanted to do bi-drectional
authentication for some reason.