Subject: [Pana] Re: Question on draft-ietf-pana-pana-11

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 03 Apr 2006 13:18:21 -0400

Hi Lakshminath,

This problem is known to be compound authentication problem.
Cryptographic binding is the key solution for this class of problem.

Here is a list of references on this problem:

- http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-puthenkulam-eap-binding-04.txt

- http://www.saunalahti.fi/~asokan/research/tunnel_extab.pdf

- Section 5 of RFC4306

Although these references are focused on MiTM attack on tunneling
authentication methods, but essentially the same attack is possible
for sequential authentication methods like NAP and ISP separate
authentication in PANA.  Compound session keys (like PANA does) is one
way of cryptographic binding.  There can be another way (like EAP
usage in IKEv2) of cryptographic binding as well.

Best regards,
Yoshihiro Ohba

On Fri, Mar 31, 2006 at 05:29:39PM -0800, Lakshminath Dondeti wrote:
> Hi,
> 
> The PANA spec in Section 11.4 says:
> In the absence of lower-layer security,
>    both authentications MUST be able to generate a AAA-Key, leading to
>    generation of a PANA SA.  The resultant PANA SA cryptographically
>    binds the two AAA-Keys together, hence it prevents man-in-the-middle
>    attacks.
> 
> I am curious about why the two AAA-keys need to be bound 
> together.  What is the perceived MiTM attack and how does 
> cryptographically binding the keys mitigate the attack?
> 
> Thanks in advance for any explanation.
> 
> thanks and regards,
> Lakshminath 
> 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 03 Apr 2006 12:20:40 -0700

Hi Yoshi,

Please bear with me as I disagree with your take on the applicability 
of compound binding to the dual authentication problem.  Perhaps I am 
wrong, but that could be due to the lack of clear explanation of the 
nature of the "separate" (or dual as I called it) in PANA.

I reread the ASOKAN paper just a little while ago and really can't 
see how it is applicable to anything PANA does.  Here is my summary 
of the compound binding problem:

* The attack is applicable if the first authentication is NOT mutual 
(as in a tunnel establishment with server-side authentication), and 
applies even if the second auth method comprises mutual 
authentication (although the second authentication should be possible 
to run in the clear)
* If client verifies the server's ID as it should, nothing needs to be done!

Do you agree with that?

So, let's try and explore the NAP and ISP authentication in 
PANA.  First, I can't say I understand the concept of the "lower 
layer" being insecure, perhaps that needs to be elaborated.  To 
elaborate my question, I am looking for specifics on the requirements 
on the lower layer that might relax the PANA requirement of compound 
binding and also the end-points of the lower layer. The second 
question I have is what the Man-in-the-middle might be able to do if 
the NAP EAP method is key generating and mutually authenticating (and 
in fact might be compound-bound in itself) and the ISP EAP method is 
not.  Oh, and where is the MiTM situated in the PANA network diagram.

Thanks in advance for your responses.

regards,
Lakshminath

At 10:18 AM 4/3/2006, Yoshihiro Ohba wrote:
>- 
>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-puthenkulam-eap-binding-04.txt
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 03 Apr 2006 17:11:18 -0400

Hi Lakshminath,

> * If client verifies the server's ID as it should, nothing needs to be done!

I think ASOKAN's paper addresses one aspect but not all aspects of the
compound binding problem.  In general, the compound binding problem is
applicable even if two authentication methods (tunnelled or sequenced)
support mutual authentication.  This is described in
draft-puthenkulam-eap-binding-04.txt:

"
The vulnerability exists as long as both sides are not required to
demonstrate participation in the previous "tunnel authentication" as
well as subsequent authentications, and as long as keys derived during
the exchange are not dependent on material from *all* of the
authentications.
"

I can show one example.  A MiTM uses EAP method A for NAP
authentication and EAP method B is for ISP authentication where method
A support key generation and mutual authentication.  EAP method B may
or may not support key generation and mutual authentication, but it
does not matter.

Let's assume that only the AAA-Key generated by NAP authentication is
used for deriving PANA_AUTH_KEY and PaC-EP-Master-Key.

Assume also that the MiTM has its own credentials for method A.  The
MiTM can succeed NAP authentication using method A with its own
credentials.  In the ISP authentication the MiTM just forwards method
B between legitimate PaC and PAA.

Without cryptographic binding between methods A and B, the MiTM will
succeed PANA authentication with the legitimate PAA and be able to
gain access instead of the legitimate PaC.

legitimate             MiTM                 legitimate
PaC                                            PAA
                                  PANA
    |                   |  NAP authentication   |
    |                   |   (method A)          |
    |                   |<--------------------->|
    |                   |  PANA PFER/PFEA       |              
    |                   |<--------------------->|
    |                   |         PANA          |
    |     PANA          |  ISP authentication   |
    |   (method B)      |      (method B)       |
    |<----------------->-<--------------------->|
    |                   |  PANA PBR/PBA         |
    |                   |<--------------------->|
    |                   |                       |

> layer" being insecure, perhaps that needs to be elaborated.  To 

Please see draft-ietf-pana-framework-06.txt for more detailed
explanation.

> not.  Oh, and where is the MiTM situated in the PANA network diagram.

Please see the above example, which also covers your scenario in which
only method A is key generating and mutually authenticating.

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 03 Apr 2006 14:48:58 -0700

Hi,

Thanks for the quick response.  It looks like we have different 
interpretations of the problem description (no matter, we should be 
able to resolve it with your example below).  My reading of the above 
paragraph is that the problem is applicable *only if* both sides are 
not required to demonstrate participation in the "first" (previous is 
the word used above) "tunnel authentication."  For instance if the 
first authentication is mutual, then compound binding is not 
necessary.  The first mutually authenticated tunnel establishment 
process will make sure that there is no MiTM.

>or may not support key generation and mutual authentication, but it

If the two authentications are independent and in succession/par of 
each other, the second authentication must also be mutually 
authenticating.  The only issue is whether it MUST be key generating 
or not.  (I was not precise about that in my email, apologies!).  My 
contention is that a protected ISP authentication result indication 
(RI) from the backend server to the EP is sufficient.  The keymat 
from the first authentication can be used for secure association 
protocol between the PaC and the EP and if the EP has a protected ISP 
RI, your MiTM won't be successful with the attack you describe 
here.  Do you agree?

One further issue is that if the MiTM is beyond the EP, there is no 
protection from the compound binding either.

thanks and regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 03 Apr 2006 18:52:54 -0400

> process will make sure that there is no MiTM.

Maybe my interpretation is based on a broader definition of the
problem where only sequential authentication methods exist without any
tunneling method (null "tunnel authentication").

> or not.  (I was not precise about that in my email, apologies!).  My 

If the lower layer is insecure, it must be key generating.

> RI, your MiTM won't be successful with the attack you describe 

First, there is no direct result indication sent from backend
authentication server to EP in the PANA framework (it is the PAA that
installs necessary filters to EP).

Second, even if there were direct protected result indication sent
from backend authentication server to EP, I don't understand why MiTM
won't be successful in case there is no cryptographic binding between
the two authentication methods, if both NAP and ISP authentications
succeed and the authentication server authorizes access to the
client's device identifier (which is actually the MiTM's device
identifier) that was seen by the legitimate PAA,

> protection from the compound binding either.

An appropriate secure association protocol run between PaC and EP
after the PANA authentication and authorization phase provides further
protection regardless whether the MiTM is beyong the EP or not.

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 03 Apr 2006 20:51:10 -0700

Hi Yoshi,

Thanks again.  Please see inline:

>tunneling method (null "tunnel authentication").

Tunnel may be a loaded word, but I think you get my point, if the 
first EAP authentication (say the NAP authentication) authenticates 
both parties, and if tunneled, say takes into consideration the 
compound binding attack and derives the AAA-key, then MiTM attack is avoided.

>identifier) that was seen by the legitimate PAA,

All I am saying here is that if the second authentication is mutually 
authenticating (no MiTM) and if the result indication is sent from 
the PAA to the EP (as long as a key can be sent, an RI can be sent, 
right?), then you'll achieve equivalent functionality to mixing the two keys.

Your note on a MiTM claiming another client's device ID is not 
possible since the MiTM cannot provide the other device's credentials 
to the AS.  Note that the ISP authentication is independent of the 
NAP authentication.  Both are mutually authenticating is the assumption.

>protection regardless whether the MiTM is beyong the EP or not.

No amount of protection on the path between the PaC and the EP will 
be sufficient against an adversary on the link from the EP to the network.

What I am looking for is a clarification that compound binding is not 
necessary for the above reasons and a protected RI is sufficient to 
bind the two authentications.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 04 Apr 2006 09:09:49 -0400

> compound binding attack and derives the AAA-key, then MiTM attack is 

My point is, if the first EAP authentication (whether it is tunneled
or not) is not cryptographically bound to subsequnet EAP
authentication(s), then MiTM attack is not avoided.

> right?), then you'll achieve equivalent functionality to mixing the two 

I don't think so.  Please see my comment below.

> NAP authentication.  Both are mutually authenticating is the assumption.

I think you are making some assumption here.  If you assume device
authentication for ISP authentication, then I think the assumption is
too strong to relax the cryptographic binding requirement.  When the
credentials used for ISP authentication are not bound to a particular
device identifier, then the MiTM attack is not avoided without
cryptographically binding the two EAP runs, even if both are mutually
authenticating.

> be sufficient against an adversary on the link from the EP to the network.

Sorry I was going too far in this specific statement.  The correct
statement would be:

"
An appropriate secure association protocol run between PaC and EP
after the PANA authentication and authorization phase provides further
protection if the MiTM is beyond the EP.
"

> bind the two authentications.

I don't think we can relax the cryptographic binding requirement if
the justification for it is based on strong assumption.

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 04 Apr 2006 12:30:27 -0700

Hi Yoshi,

Thanks again for your patient discussion on this topic.  I have some 
follow-up comments:

>On Mon, Apr 03, 2006 at 08:51:10PM -0700, Lakshminath Dondeti wrote:

<snip>

>authentication(s), then MiTM attack is not avoided.

<snip>

>cryptographically binding the two EAP runs, even if both are mutually

I think we are getting closer to an agreement here.  The AS/PAA must 
know the device IDs corresponding to the NAS authentication and the 
ISP authentication, so that they can bind the two AAA-keys, 
right?  So all I am saying is while binding the keys is one option, 
equivalent protection can be achieved by sending the NAS AAA-key and 
sending a binding between the NAS ID and the ISP ID (more precisely, 
L2 and L3 identifiers) to the EP.  PANA does have messages to support 
this kind of ID binding, right?

>protection if the MiTM is beyond the EP.

Thanks for the clarification, but I don't see why any protection 
beyond the EP is possible with a SEC association between the PaC and 
the EP.  Please explain why an attacker situated after the EP cannot 
spoof identities on the packets

>the justification for it is based on strong assumption.

I don't understand this part.  The assumption is the same as that 
applies to key delivery to the EP, no?

thanks and regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 04 Apr 2006 16:15:59 -0400

Hi Lakshminath,

On Tue, Apr 04, 2006 at 12:30:27PM -0700, Lakshminath Dondeti wrote:
> I think we are getting closer to an agreement here.  

There is some misunderstanding.  Please see my comment below.

> The AS/PAA must 
> right?  

This is correct, except s/NAS/NAP/ I guess.

> So all I am saying is while binding the keys is one option, 

I don't think your scheme provides equivalent protection as the
cryptographic binding defined in the PANA specification.  In the MiTM
attack I explained, the MiTM uses its own device identifier for PANA
communication with the legitimate PAA as well as for application
traffic via the EP.  As a result, the PAA will send MiTM's device
identifier and a PaC-EP-Master-Key to the EP, not the device
identifier of the legitimate PaC.

> spoof identities on the packets

Sorry for the confusion, I meant the case where the attacker is beyond
the EP *when seeing the attacker from the network side*, i.e., the
attacker is between the PaC and EP.  If the attacker is between EP and
the network, then the SA between the PaC and EP does not help, as you
stated.

> applies to key delivery to the EP, no?

No.

"Key delivery to the EP" is for binding the PaC's device identifier to
the key generated as a result of PANA authentication, where the EAP
run(s) within the PANA authentication may use any kind of
authentication credentials (device credentials or user credentials).

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 05 Apr 2006 16:09:41 -0700

Hi,

Sorry for the delay in my response, let me attribute it to a spike in 
Nomcom activity.  I read 4016 again and it seems to support my 
statements, specifically,

Requirement 3 and the related text support my statement on compound 
binding.  It applies to ISP or NAP authentication individually and 
does not necessarily apply to the dual authentication case.

Requirement 7 says

    PANA MUST securely bind the authenticated session to the device
    identifier of the client, to prevent service theft.  PANA MUST be
    able to bootstrap a shared secret between the PaC and PAA that can be
    further used to set up a security association between the PaC and EP
    to provide cryptographic protection against service theft.

So, binding authenticated session to device IDs as well as 
cryptographic protection are both supported as per 4016.  I am 
curious what changed between then and now.

Perhaps this WG consensus as in 4016 might be more convincing to you?

thanks and regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 05 Apr 2006 19:38:27 -0400

To tell the history, when we were working on the threat analysis, NAP
and ISP separate authentication was not yet considered as a target
scenario (I mean NAP and ISP separate authentication is relatively new
scenario).  This is why RFC 4016 is silent about the cryptographic
binding for NAP and ISP separate authentication while it has a
cryptographic binding requirement on tunneling methods.

Regardless RFC 4016, cryptographic binding for NAP and ISP
authentication is needed.  Thus, lack of cryptographic binding
requirement for NAP and ISP separate authentication in RFC 4016
cannot be used for justifying your statements.

If you have further questions, please let us know.

Best regards,
Yoshihiro Ohba

On Wed, Apr 05, 2006 at 04:09:41PM -0700, Lakshminath Dondeti wrote:
> >> >> right?), then you'll achieve equivalent functionality to mixing the 
> >two
> >> >> keys.
> >> >

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 05 Apr 2006 16:49:00 -0700

So 4016 is already obsolete!  And, I still don't have an answer on 
why the protected RI is not ok.  I guess we'll leave it at that!

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 05 Apr 2006 20:50:34 -0400

> why the protected RI is not ok.  I guess we'll leave it at that!

I explained it, but just to summarize:

When there is a MiTM, if there is no cryptographic binding between the
two AAA-Keys the following steps can be taken:

1. the PANA_MAC_Key and PaC-EP-Master-key are generated using the
AAA-Key generated by NAP authentication only.  The MiTM can possess
this AAA-Key because it uses its own credentials for NAP
authentication.  As a result, PANA authentication will succeed,
because the MiTM does not have to possess the AAA-Key generated by ISP
authentication to derive the PANA_MAC_Key.  (The legitimate PaC has
the AAA-Key generated by ISP authentication.)

Note: the PANA_MAC_Key and PaC-EP-Master-Key have been compromised in
this step, because of the lack of the cryptographic binding.  So the
subsequent steps relying on those keys are compromised as well.

2. As a result of the successful PANA authentication, the PAA will
send the PaC-EP-Master-Key and MiTM's device identifier to the EP over
a secure channel (this is the protected RI in my understanding, if
not, please clearly define what exactly protected RI means).  The EP
will associate the PaC-EP-Master-Key with the MiTM's device
identifier, instead of the legitimate PaC's device identifier.

3. the MiTM will run a secure association protocol with EP using the
PaC-EP-Master-Key and the MiTM's device identifier.  The secure
association protocol will also succeed and thus the MiTM attack will
succeed.

If there is cryptographic binding between the two AAA-Keys, Step 1
will fail because PANA authentication will not succeed.  This is
because the MiTM does not possess the AAA-Key generated by ISP
authentication while the key is required to derive the correct
PANA_MAC_Key and PaC-EP-Master-Key.

Hope this helps,
Yoshihiro Ohba

> >> >> >> compound binding attack and derives the AAA-key, then MiTM attack 
> >is
> >> >> >> avoided.
> >> >> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 5 Apr 2006 23:38:38 -0400

In case my summary in a separate email is not sufficient to make you
understand, there is another information.

EAP-after-EAP mode in an early IEEE 802.16e draft had the same
vulnerability on MiTM attack as your scheme due to the lack of
appropriate cryptographic binding.  The vulnerability was fixed during
the EAP WG expert review of 802.16e draft (I was one of the
reviewers), by adding essentially the same cryptographic binding
functionality as PANA defines.  Detailed review comments and the
response from IEEE 802.16 WG are available at:

http://ieee802.org/16/liaison/docs/L80216-05_041.pdf

http://ieee802.org/16/liaison/docs/L80216-05_049.pdf

Best regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 07 Apr 2006 10:15:34 -0700

Hi Yoshi,

First I will note that I got stuck with the first item (1) in your 
email below. I don't think key compromise is possible.  If it is, the 
entire protocol is broken.

I finally found some time yesterday to analyze this at length with 
the help of some colleagues and here is the conclusion:

In case of PANA,
a) (with the assumptions of lack of lower protection etc.,), and
b) if the key from the first authentication is used only for 
integrity protection and not encryption, and
c) since there is no way for the PAA or the AAA server(s) to identify 
the L2 or L3 identifiers of the entity that holds the NAP NAI and/or 
ISP NAI, and
d) since there is no way to figure out the relationship between a NAP 
NAI and an ISP NAI (whether or not the same peer/PaC holds them)

when *all* those conditions being true, there is in fact a man in the 
middle attack and that can be mitigated with key binding.  I have to 
note that simply saying this applies to all multiple EAP 
authentications is being imprecise.  I request that some of this text 
be written in the PANA specification for completeness.

Finally, many thanks for continuing the discussion.  It led to my 
analysis of it.  You were probably alluding to some of this, but 
unfortunately, it was not clear perhaps due to the nature of email 
discussion.  I hope you find this constructive, and if not, my 
sincere apologies for any time you feel was wasted in this email exchange.

many thanks and best regards,
Lakshminath

At 05:50 PM 4/5/2006, Yoshihiro Ohba wrote:
> > >> >> >> >problem where only sequential authentication methods 
> exist without
> > >> >any

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 07 Apr 2006 18:18:28 -0400

Hi Lakshminath,

> entire protocol is broken.

I got it.  My expression was not accurate on item (1).  Key itself is
not compromised, but key is not bound to both EAP authentications.

> a) (with the assumptions of lack of lower protection etc.,), and

Yes.  This is described in the last paragraph of Section 4.8.2 
and Section 11.4 of pana-pana.

> integrity protection and not encryption, and

Even if the key is used for both integrity protection and encyption,
the attack is still possible as long as the attacker has the
encryption key.  Am I missing something?

> the L2 or L3 identifiers of the entity that holds the NAP NAI and/or 

I am not sure removing this assumption exempts from crypt binidng.
What happens if the MiTM is spoofing the legitimate PaC's L2 or L3
identifiers?

> NAI and an ISP NAI (whether or not the same peer/PaC holds them)

I am not sure whether removing this assumption provides the same level
of protection as cryptographic binding (I am wondering if other type
of MiTM is still possible by removing the assumption).  Perhaps a
formal proof might be needed to removing this assumption for exempting
from crypt binding.

> be written in the PANA specification for completeness.

Condition a) is already described in PANA.  I doubt b), c) and d).

> sincere apologies for any time you feel was wasted in this email exchange.

Sorry for my distributed logics and several incorrect description my
emails.  Anyways, this is interesting dicussion to me.  Identifying
conditions for exempting from crypt binding seems to be a new topic
and need more research.  I'd like to continue the discussion with you
and your colleagues privately if you like.

Thank you,
Yoshihiro Ohba

> >> >> >> >> be sufficient against an adversary on the link from the EP to 
> >the
> >> >> >> >network.
> >> >> >> >
> >> >> >> >> What I am looking for is a clarification that compound binding 
> >is
> >> >not

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 07 Apr 2006 15:39:46 -0700

>not compromised, but key is not bound to both EAP authentications.

Yes, thanks for the clarification.  We have a similar understanding then.

>and Section 11.4 of pana-pana.

Yes, you and I noted this earlier.

>encryption key.  Am I missing something?

Here is how I think it works.  If the adversary also has finished the 
NAP authentication, it can be a MiTM on a legitimate Peer's ISP 
authentication by stripping the AUTH payload.  The ISP authentication 
end-2-end is still between the peer and it's AAA server, but the PAA 
is fooled to believe that the MiTM is doing the ISP 
authentication.  The MiTM can replace some fields that the 
Authenticator cares for and recompute the AUTH tag with its key.  If 
the exchange is encrypted, the MiTM can't do much.  So, encryption 
fixes the problem.  I wonder what the AUTH tag's purpose was since it 
doesn't serve this important requirement :-).

>formal proof might be needed to removing this assumption for exempting

(c) and (d) might be practical or not depending on deployments and 
use cases.  But, it is clear that the problem is end-2-end 
authentication uses different identities compared to the identities 
that the EP and or PAA might see.  Some of the binding I am talking 
about is possible with configuration.  I guess it's possible to prove 
it formally, but it would be based on a set of assumptions and 
drawing logical conclusions from there.  If you are interested, we 
can explore that off-line and report back on the list.  I am 
interested in it as well.

>Condition a) is already described in PANA.  I doubt b), c) and d).

 From my explanation above, please see if (b) is clear.
On c and d, let's see if we can come up with an agreeable line of 
thinking offline and report back on this list.

>and your colleagues privately if you like.

As noted earlier, sure, please initiate the discussion offline and 
I'll add my colleagues as applicable and necessary.

best wishes Yoshi,
Lakshminath

> > >> >>    able to bootstrap a shared secret between the PaC and 
> PAA that can
> > >be
> > >> >> >> >> >An appropriate secure association protocol run 
> between PaC and
> > >EP

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 07 Apr 2006 20:17:43 -0400

I have one clarication.  The PANA specification should not be blocked
by the offline discussion mentioned below, as there is no issue with
the PANA protocol.  My position is that I am just interested in deep
analysis on relaxing assumptions on cryptographic binding for multiple
EAP authentications in general.

Yoshihiro Ohba

On Fri, Apr 07, 2006 at 03:39:46PM -0700, Lakshminath Dondeti wrote:
> >> >> >>    further used to set up a security association between the PaC 
> >and
> >> >EP
> >> >> >> >> >> to the AS.  Note that the ISP authentication is independent 
> >of
> >> >the
> >> >> >> >> >too strong to relax the cryptographic binding requirement.  
> >When
> >> >the
> >> >> >> >> >> >after the PANA authentication and authorization phase 
> >provides
> >> >> >> >further
> >> >> >> >> >I don't think we can relax the cryptographic binding 
> >requirement
> >> >if
> >> >> >> >"Key delivery to the EP" is for binding the PaC's device 
> >identifier
> >> >to