Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 May 2006 16:45:39 -0700 (PDT)

I have reviewed the PANA framework document, the PANA protocol spec, and 
the PANA/IPsec document. After reading all these documents, I still do 
not understand why PANA is useful.

The PANA framework document claims that it can be used along with IEEE 
802.11i.  However, IEEE 802.11 reviewed the document, and came to a 
different conclusion:
http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc

The other potential scenario outlined by the framework document is use 
along with IPsec.  However, IKEv2 already supports EAP authentication, so 
I don't understand why PANA would be used for that scenario instead of 
IKEv2. 

I do understand the potential need for EAP to be encapsulated over IP.  
However, in practice PANA is more complex than EAP over UDP 
(see draft-thomson-nacp-02.txt), which looks like it is on the road 
to becoming the defacto standard for EAP encapsulation over IP. 

So from what I can tell, in each potential usage scenario PANA is 
either not feasible, is more complex than an established alternative, 
or has been rejected by the SDOs that have examined it.

-------------------------------------------------------------------
Sam Hartman said:

Hi.  Speaking as an individual, I'd like to make an explicit call for
members of the IETF community not involved in the PANA working group
to review draft-ietf-pana-framework.  Please speak up if you have done
such a review or attempted such a review and been unsuccessful.  Let
us know what you think PANA is intended to be useful for and whether
you think it is actually useful.

My strong hunch is that we've chartered work for some reason, and now
that the working group is nearing the end of its charter, we still
don't understand why we want this thing we've built and whether it's a
good idea.  People aren't screaming not so much because they are happy
with results but because no one actually understands PANA.

I understand that there's a strong presumption that once chartered,
work is useful.  I'd like to challenge this presumption enough to get
people to actually read the document.  If people not involved in the
effort sit down, read the document and understand what it's all about,
my concern is satisfied.  But if enough people try to read the
document, try to understand and fail, we're not done yet.  We
certainly cannot have consensus to publish something we've tried and
failed to understand.

It's not just me.  I've been trying to find people outside of PANA who
claim to understand the effort and what it's good for and why
link-layer solutions are not better.  When the first discussion of
PANA hit the IESG, I asked other IESG members why PANA was a good idea
and what problem it solved.  "Don't go there," was the advice I got
from the responsible AD.

At that time (a year and a half ago) there was no one on the IESG who
claimed to understand PANA or to think it was a good idea.

I'm fairly sure that with the possible exception of Jari (who is a
technical advisor to PANA), that's still true.

The security community has been trying to understand PANA.  I've sent
multiple security reviewers at the PANA document.s They always come
back fundamentally confused about what PANA is trying to do or about
whether it is a good idea.  They end up focusing on some detail or
another and asking for some minor part of the system to be fixed.  But
I don't get the impression from the reviews they understand the
overall picture; explicit discussion of this also indicates that they
are not confident in their understanding nor do they know whether it
is a good idea.

We keep running back over the same ground, still confused and still
trying to muddle through to no real effect.

I've tried to understand it myself.  I tried to understand in the BOF.
It was very clear to me leaving the original PANA BOF that something
was very confused.  Every year or so since I've tried to go back and
figure out what I missed.  Eventually though I've started wondering
whether the problem wasn't me, but was an actual lack of clarity.

So, folks can you please help us all out.  Especially if the internet
area is not your primary focus, especially if you've never heard of
PANA before, take a look at the framework document and all their other
documents.  Do you get it?  Is it a good idea?

Thanks for your time.

P.S.  Again, this is me speaking as an individual.  At this late
stage, it would be entirely inappropriate for me to take actions as an
AD claiming that we didn't understand a problem without a strong
community consensus.

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 May 2006 18:36:01 -0700

Hi Bernard,

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Thursday, May 25, 2006 4:46 PM
> To: [email-masked]
> Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
> 

Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful... 

> http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-

This is an inaccurate reading of the IEEE response (and you are the
liaison). You are aware that "virtual open-access AP" mode is OK. One of the
two alternatives we proposed had an issue, and the other one still holds.

> I don't understand why PANA would be used for that scenario instead of

You had commented on that earlier and I had explained it.
http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html. If not
clear, please follow up from there (we don't need to go back to your
original question).

> I do understand the potential need for EAP to be encapsulated over IP.

Thank you. 

> to becoming the defacto standard for EAP encapsulation over IP.

De-facto? Could you please elaborate how it is becoming a de-facto standard?

Besides. Of course PANA is more complex than EAPoUDP. The latter (an
individual I-D) has very limited applicability. If it were to handle
mobility and wireless, it'll also grow in complexity. Just to get some sense
of it, compare 802.1X and 802.11r.

> or has been rejected by the SDOs that have examined it.

Which SDOs? Please give us more detail.

Thank you.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 May 2006 18:54:21 -0700 (PDT)

> understand how you can still claim you don't understand why PANA is

The framework doesn't seem to talk much about simple EAP over IP 
scenarios, so I have assumed this is not the major focus. 

> You are aware that "virtual open-access AP" mode is OK. One of the

Right.  I was referring only to the WPA/WPA2 scenarios. 

> De-facto? Could you please elaborate how it is becoming a de-facto standard?

EAP over UDP is one of the foundation technologies for Network Endpoint 
Assessment (NEA).  As I understand it, EAPoUDP is being made available on 
most operating systems, and is in the process of being deployed by many 
enterprise customers. 

> individual I-D) has very limited applicability.  

As I understand it, EAP over UDP is mostly being deployed for wired access 
scenarios where IEEE 802.1X might not work well (e.g. multiple hosts 
sharing a port).  

> Which SDOs? Please give us more detail.

As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has 
evaluated the PANA framework document.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 May 2006 20:38:49 -0700

> scenarios, so I have assumed this is not the major focus.

I am sure you read RFC 4058 (like anyone who claims they don't understand
PANA should have done). RFC 4058 said:

   PANA will carry EAP above IP in order to enable any authentication
   method on any link-layer.

> Right.  I was referring only to the WPA/WPA2 scenarios.

Your earlier statement did give another impression, like PANA does not work
with 802.11i at all. Thanks for clarifying it now!

> most operating systems, and is in the process of being deployed by many

Yes, that individual I-D is productized as a proprietary protocol by one
company (Cisco). Client-side software may be made available by them for
various platforms (note PANA is already made available as an open source
--both client and software side). If Cisco develops a proprietary protocol
on its own for a subset of our work, should we now stop what we do at IETF?
Is that where this whole fuss is coming from now?

> evaluated the PANA framework document.

How does this explain your "rejected by the SDOs" claim? IEEE 802.11
provided a review feedback and they fixed few important problems and
acknowledged the applicability of our other alternative solutions. How is
that a rejection?!? 

As for 3GPP2, I can get into really gory details of what has been happening
there, but it's not technical at all (if you are familiar with 3GPP2 and the
relevant players in this discussion, you can guess).

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 May 2006 00:17:24 -0400

> to becoming the defacto standard for EAP encapsulation over IP. 

I don't think draft-thomson-nacp-02.txt is something to become an IETF
standard EAP over UDP protocol because of its lack of security.  In
fact the draft admits:

"
   If breach of confidentiality and deliberate attacks on the integrity
   of the NACP protocol itself are a significant risk in certain
   deployment environments, NACP should be protected by a protocol that
   offers confidentiality and/or packet authentication, integrity and
   protection against replay e.g.  IPSEC [RFC2401].
"

Why IPsec is needed to carry EAP?  What is authentication protocol for
bootstrapping IPsec to protect NACP, perhaps EAP over IKEv2??

I have other security-related issues on NACP.  My view is that secure
enhancement of NACP will be equivalent to the EAP over UDP protocol
the IETF is standardizing, PANA.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 May 2006 21:20:07 -0700 (PDT)

> company (Cisco). 

As I understand it, EAP over UDP is one of the items proposed for 
standardization in the NEA WG.  That leads me to wonder whether the IETF 
will be chartering multiple WGs to standardize EAP encapsulation over IP. 

Although my understanding of both PANA and NEA is no doubt 
incomplete/wrong/confusled, having multiple EAP encapsulation standards 
seems duplicative to me.

> relevant players in this discussion, you can guess).

The issue is that integration of PANA with link layer technologies 
requires the support of the organizations that own those link layers.  
Without that link layer integration (for whatever reason) the scenarios 
can't be realized, at least in a mainstream way. 

It seems to me that one of the motivations for PANA is to *avoid* link layer 
dependencies in situations where link layer technology is inadequate/can't 
be deployed, and a forklift upgrade isn't in the budget.  In those 
circumstances, integration with link layers or IPsec VPN technology is 
not under consideration -- because that would require a forklift upgrade.

For example, the wireless hotspot case where something more sophisticated 
than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN 
deployment isn't a realistic alternative.  Or the shared wired media case 
where "network port authentication" doesn't really work, and wholesale 
switch port replacements aren't affordable.  In both of those cases, EAP 
over IP might provide a light weight, easily deployed solution.

Yet, rather than focusing on the specific scenarios in which PANA might 
be compelling, the PANA framework document tries to cover a wide 
range of potential uses, trying to position PANA for use in scenarios 
where the case is less obvious.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 May 2006 21:24:03 -0700 (PDT)

> the IETF is standardizing, PANA.

Can you describe why the security of PANA is better than EAP over UDP 
(NACP)?  I had thought that they were more or less equivalent, since 
neither approach mandates protection. 

But maybe I am missing something?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 26 May 2006 01:29:27 -0400

> neither approach mandates protection. 

NACP does not have its own integrity protection mechanism while PANA
has.  It is true that PANA AUTH AVP is optional, but the use of
protection is mandatory when an EAP method that is capable of deriving
keys is used.  This is described in the PANA specification draft.

We can discuss security aspects more, but what I would really like to
say in this thread is that discussing usefulness of PANA or any other
EAP transport without deep security analysis does not appear to be the
right thing.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 May 2006 23:08:18 -0700

> standardization in the NEA WG.  

You misunderstood it, despite the clear text in their charter:

...

  Requirements need to
  be defined for an EAP over L3 transport for L3 access scenarios.

...

  * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG)
    and work with ADs to identify the WG responsible for accommodating
    protocol requirements that are not currently being met.

> That leads me to wonder whether the IETF

It is not suggested anyways.

> requires the support of the organizations that own those link layers.

Not necessarily. Why do you think so? 802.11 is a counter example. DSL is a
counter example. 

> over IP might provide a light weight, easily deployed solution.

Are you referring to NACP as "EAP over IP"? You acknowledged it is designed
for wired networks. It is not even useful for wireless. Won't work.

> where the case is less obvious.

I think that would have been unnecessarily limiting, given that we designed
a protocol that can naturally work in variety of scenarios.

Alper

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 08:45:06 -0400

What is the current state of the nea WG?  I don't see it listed at
http://ietf.org/html.charters/wg-dir.html

- Ralph

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 May 2006 08:27:29 -0400

In reading the PANA Framework document,  what I read seemed to me to 
be more of a "system" or "solution" document than a clean IETF 
protocol framework.

I saw efforts to address three different problems:
1) Securing an otherwise unsecured link, when the access node is not 
known to the client in advance.
2) Selecting an authorization (charging, possibly packet handling) service
3) Authenticating the user

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.

And spell out in clear English what use case needs that problem 
solved.  I can read between the lines and start to guess.  But the 
document is quite unclear.  The appendix about DSL is not helpful in 
that regard.

Yours,
Joel M. Halpern

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 May 2006 17:21:06 +0300

>http://ietf.org/html.charters/wg-dir.html
NEA held a BOF in Dallas, and I believe they are planning
to hold a 2nd BOF in Montreal.

--Jari

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 May 2006 11:05:14 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    >> > Yes, that individual I-D is productized as a proprietary
    >> protocol by one > company (Cisco).
    >> 
    >> As I understand it, EAP over UDP is one of the items proposed
    >> for standardization in the NEA WG.

    Alper> You misunderstood it, despite the clear text in their
    Alper> charter:

    Alper> ...

    Alper>   Requirements need to be defined for an EAP over L3
    Alper> transport for L3 access scenarios.

I don't think he misunderstood.  IT may not be in their charter, but
they definitely did want to standardize EAP over UDP in at least some
versions of NEA.

My question is more why do they need EAP in situations where they are
not running at the link layer than why do they want or not want PANA.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 May 2006 10:58:57 -0400

>>>>> "Ralph" == Ralph Droms <[email-masked]> writes:

    Ralph> What is the current state of the nea WG?  I don't see it
    Ralph> listed at http://ietf.org/html.charters/wg-dir.html

It had a BOF at the last IETF.

It seems highly likely it will either have a proposed WG or BOF again.
(Russ and I have received both a charter and a BOF proposal)

Russ is shepherding the effort.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 11:32:44 -0400

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 11:32:44 -0400

Sam - I see where the nea BOF was more-or-less associated with the Internet
Area at IETF 65.  Do you expect that nea would (if eventually chartered)
land in Internet or Security?

- Ralph

n <[email-masked]>
Cc: [email-masked]
Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?

Sam - I see where the nea BOF was more-or-less associated with the Internet
Area at IETF 65.  Do you expect that nea would (if eventually chartered)
land in Internet or Security?

- Ralph

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 08:34:54 -0700

Joel M. Halpern wrote:
> media independent technique better than just using a browser is needed, 
> then solve that problem.  Personally, I would find the work far more 
> persuasive if it did not also try to solve the problem of creating an 
> IPSec association to the access device, nor of the authorization 
> selection problem.
> 
> And spell out in clear English what use case needs that problem solved.  
> I can read between the lines and start to guess.  But the document is 
> quite unclear.  The appendix about DSL is not helpful in that regard.

Although not a guaranteed way to distinguish among criticisms, it can be helpful 
to categorize them as either "It will not work" versus "I don't like it". The 
former indicates a basic technical flaw, and the latter a matter of preference.

If it is common for readers of a specification to fail to understand what it is 
for then it has, perhaps, the most basic kind of technical flaw.  How can a 
specification succeed if there is confusion about its implementation or use?

By contrast observations such as "there are better solutions" moves into the 
fuzzier and more subjective realm of trying to predict market preferences. The 
IETF is not very good at making these predictions.  Absent any indication of 
actual harm that would ensue from publishing a specification, fear that no one 
will adopt it or that there will be multiple solutions seems an inappropriate 
basis for denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a factor in 
deciding whether to charter the work in the first place; however as Sam noted, 
we are rather late in the process.)

In any event, I would claim that concerns over who will use PANA fall into the 
"I don't like it" category, since it basically seeks to make statements about 
market preferences, which is a small step from personal preferences.

Having looked over this thread and the -framework document a bit, I find myself 
unclear which of the two lines of concern is being pursued, although I impressed 
by the degree of confusion about PANA after what appears to be considerable 
effort to understand it.  This does not bode well for community understanding, 
and that of course does not bode well for adoption and use.

I would find it particularly helpful to have a concise statement from someone 
who says that PANA will not work.  Cannot be implemented (properly) by virtue of 
technical errors or documentation too confusing to understand.  Or cannot be 
deployed and used, by virtue of administrative complexity or, again, 
documentation too confusing to understand.

Absent this, I will ask why it is productive to note that the emperor is 
pursuing an idiosynchratic sartorial style?

d/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 May 2006 07:57:16 -0700

>to hold a 2nd BOF in Montreal.

Mailing list info: <https://www1.ietf.org/mailman/listinfo/nea>. The 
post-Dallas discussions have been quite fruitful, and the discussion 
this week particularly so.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 11:44:11 -0400

Dave - one quick follow on to your observation about "will not work" that
falls somewhere between "will not work" and "don't like it".  There is
another possibility: "works, but there's a much simpler way to meet the same
requirements"...

- Ralph

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 May 2006 07:57:16 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 11:44:11 -0400

- Ralph

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 26 May 2006 11:46:20 -0400

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.
Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to 
explain somewhere (the framework document would seem the obvious 
place) why there is a need for a new solution.

I am not claiming that the PANA protocol can't work.  As was said 
many years ago "with sufficient thrust, pigs will fly."  But that 
does not make flying pigs a good thing.

Yours,
Joel M. Halpern

At 11:34 AM 5/26/2006, Dave Crocker wrote:

>Joel M. Halpern wrote:
>>EAP over IP (or UDP, or link) is about authenticating the user.  If 
>>a media independent technique better than just using a browser is 
>>I can read between the lines and start to guess.  But the document 
>>is quite unclear.  The appendix about DSL is not helpful in that regard.
>
>
>Although not a guaranteed way to distinguish among criticisms, it 
>can be helpful to categorize them as either "It will not work" 
>versus "I don't like it". The former indicates a basic technical 
>flaw, and the latter a matter of preference.
>
>If it is common for readers of a specification to fail to understand 
>what it is for then it has, perhaps, the most basic kind of 
>technical flaw.  How can a specification succeed if there is 
>confusion about its implementation or use?
>
>By contrast observations such as "there are better solutions" moves 
>into the fuzzier and more subjective realm of trying to predict 
>market preferences. The IETF is not very good at making these 
>predictions.  Absent any indication of actual harm that would ensue 
>from publishing a specification, fear that no one will adopt it or 
>that there will be multiple solutions seems an inappropriate basis 
>for denying publication.  (On the other hand, strong indication of 
>community interest in deplying a specification is supposed to be a 
>factor in deciding whether to charter the work in the first place; 
>however as Sam noted, we are rather late in the process.)
>
>In any event, I would claim that concerns over who will use PANA 
>fall into the "I don't like it" category, since it basically seeks 
>to make statements about market preferences, which is a small step 
>from personal preferences.
>
>Having looked over this thread and the -framework document a bit, I 
>find myself unclear which of the two lines of concern is being 
>pursued, although I impressed by the degree of confusion about PANA 
>after what appears to be considerable effort to understand it.  This 
>does not bode well for community understanding, and that of course 
>does not bode well for adoption and use.
>
>I would find it particularly helpful to have a concise statement 
>from someone who says that PANA will not work.  Cannot be 
>implemented (properly) by virtue of technical errors or 
>documentation too confusing to understand.  Or cannot be deployed 
>and used, by virtue of administrative complexity or, again, 
>Absent this, I will ask why it is productive to note that the 
>emperor is pursuing an idiosynchratic sartorial style?
>
>d/
>

---

From: "Antonio F. Gómez Skarmeta" <[email-masked]>
Date: Fri, 26 May 2006 17:49:23 +0200

Dave Crocker escribió:

> Although not a guaranteed way to distinguish among criticisms, it can 
> be helpful to categorize them as either "It will not work" versus "I 
> don't like it". The former indicates a basic technical flaw, and the 
> latter a matter of preference.
>

  I totally agree with your statement, I was just thinking about sending 
a message in this line.

  I am (at least I thought I am) a scientific and as such I prefer to 
work with statement and lemas that allow me to reason with them. 
Although in some of the messages I have read there are more perceptions 
or opinions but too little technical criticism.

  In that sense I will like to see clear indication of what is not 
adequate and wrong in a more technical fashion, hence it will allow 
people to debate on it an a least explain the reason in objectives and 
not subjective ways

 My 2 cents on this

> what it is for then it has, perhaps, the most basic kind of technical 
> flaw.  How can a specification succeed if there is confusion about its 
> implementation or use?
>
> into the fuzzier and more subjective realm of trying to predict market 
> preferences. The IETF is not very good at making these predictions.  
> Absent any indication of actual harm that would ensue from publishing 
> a specification, fear that no one will adopt it or that there will be 
> multiple solutions seems an inappropriate basis for denying 
> publication.  (On the other hand, strong indication of community 
> interest in deplying a specification is supposed to be a factor in 
> deciding whether to charter the work in the first place; however as 
> Sam noted, we are rather late in the process.)
>
> In any event, I would claim that concerns over who will use PANA fall 
> into the "I don't like it" category, since it basically seeks to make 
> statements about market preferences, which is a small step from 
> personal preferences.
>
> I would find it particularly helpful to have a concise statement from 
> someone who says that PANA will not work.  Cannot be implemented 
> (properly) by virtue of technical errors or documentation too 
> confusing to understand.  Or cannot be deployed and used, by virtue of 
> administrative complexity or, again, documentation too confusing to 
> understand.
>
> Absent this, I will ask why it is productive to note that the emperor 
> is pursuing an idiosynchratic sartorial style?
>
> d/
>

-- 
------------------------------------------------------------
Antonio F. Gómez Skarmeta
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
Apartado 4021
30001 Murcia
Telf: +34-968-364607
fax: +34-968-364151

---

From: "Antonio F. Gómez Skarmeta" <[email-masked]>
Date: Fri, 26 May 2006 17:50:40 +0200

>another possibility: "works, but there's a much simpler way to meet the same

  Which one? and why it is better?

 Antonio

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 May 2006 08:58:02 -0700 (PDT)

> not running at the link layer than why do they want or not want PANA.

The simple answer is that there are situations which IEEE 802.1X cannot 
handle on wired networks.  As specified, IEEE 802.1X is "network port 
control", which means that authorization is controllable only at the port 
level.  If there is more than one host connected to a switch port, then 
that model no longer applies. 

For example, consider a user with two machines attached to a hub on a 
single port - a laptop and a desktop machine.  The desktop authenticates 
via machine credentials, and for some reason the certificate has expired 
without being renewed.  The laptop has up to date credentials.  However, 
because they are both connected to the same port, they will each attempt 
to authenticate; since the desktop machine no longer has up to date 
credentials, its authentication will fail, causing port access to be 
denied, throwing the laptop off the network.  The two machines will 
continue to cycle through authentication attempts, causing the port to 
alternatively be open and closed.

Some of the solutions that have been discussed include:

a. For the switch to keep MAC state on each port, which requires a 
additional CAM, and therefore a forklift upgrade, OR

b. For the switch to support protected Ethernet (802.1ae) and associated 
key management (802.1af) so that traffic from each host can be 
cryptographically separated, also requiring an (even more expensive) 
forklift upgrade; OR

c. For the host and routers to support EAP over UDP.  Typically this works 
by having the router recognize a new host (e.g. new entry in the ARP 
table), then challenging it via EAP over UDP.  If the host successfully 
authenticates, packets from that IP address are allowed to pass through 
the router filter; otherwise not. 

Of these approaches, b) is the most secure since it enables cryptographic 
separation between traffic from different MAC addresses, preventing
MAC address piggyback attacks as well as enabling reliable "shared media" 
operation. However, it is also the most expensive approach, since each 
port now needs to support encryption; at lines rates of 1+ Gbps this can 
be pricey. 

Approach a) is less expensive (and less ecure) than b), but also requires 
a forklift upgrade. 

Approach c) is probably the least secure, but it is also the 
least expensive approach, since no switch ports need to be upgraded. 

One might argue that approach c) is likely to represent a short-term fix 
until switches supporting a) or b) are commonly available, and therefore 
that EAP over UDP has no long-term future.  I would tend to agree with 
this, but would also observe that switches tend to have long replacement 
cycles. For example, it is common to see customers with Cat 5K switches 
that have been in place for a nearly decade with no immediate prospects 
for replacement. Those kind of customers are likely to find EAP over UDP 
appealing.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 May 2006 11:59:15 -0400

Antonio - I'm not well-informed enough about the specifics of the PANA
problem space and framework to make definitive recommendations.  I was
mostly making an observation, based on my experience, of another reaction
someone might have to a particular technology/design/protocol.

- Ralph

On 5/26/06 11:50 AM, "Antonio F. Gómez Skarmeta" <[email-masked]> wrote:

>>> someone
>>> who says that PANA will not work.  Cannot be implemented (properly) by
>>> virtue
>>> of

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 May 2006 12:08:30 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    >> My question is more why do they need EAP in situations where
    >> they are not running at the link layer than why do they want or
    >> not want PANA.

    Bernard> The simple answer is that there are situations which IEEE
    Bernard> 802.1X cannot handle on wired networks.  As specified,
    Bernard> IEEE 802.1X is "network port control", which means that
    Bernard> authorization is controllable only at the port level.  If
    Bernard> there is more than one host connected to a switch port,
    Bernard> then that model no longer applies.

Yeah.  I guess I wonder whether you are actually getting network
access authenticatino at that point or whether you are getting a
service that allows you to check posture.  It seems that a service
that simply allows you to check posture should be not EAP.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 09:13:53 -0700

> another possibility: "works, but there's a much simpler way to meet the same

ahh, good.  this nicely permits making the underlying distinction a bit more 
strongly:

"There is a much simpler way to meet the requirements" states an engineering 
preference.  Further, it often involves comparing a concrete specification 
against an unspecified idea.  The issue therefore is not whether the criticism 
is valid -- it often is -- but that it falls primarily into the "I don't like 
it" category.

If there is a better way to solve a problem, those supporting the alternative 
ought to go and specify it and gain community adoption.  Otherwise, we suffer 
the danger of preventing deployment of *any* capability, since we will always be 
waiting for work to get done on that simpler way of meeting the same requirements.

The folks who actually did the work ought get to test that work in the market 
place... unless there is a clear basis for claiming that it won't work and 
reasonable consensus that the basis is valid.

d/

ps.  The process model that informs this line of thinking says that we should be 
strict in demanding strong indication of community support, when an effort 
starts -- and I will claim while the working group proceeds -- but that it 
should not factor that into the final standardization decision.  In this latter 
stage, this concern looks too much like sour grapes.  (Not that it necessarily 
is, but that it simply is not fair to use it as a basis for rejection at that 
stage.)

---

From: Peter Dambier <[email-masked]>
Date: Fri, 26 May 2006 18:25:47 +0200

Joel M. Halpern wrote:
> problem that the WG is attempting to solve then the WG needs to explain 
> somewhere (the framework document would seem the obvious place) why 
> there is a need for a new solution.
> 
> I am not claiming that the PANA protocol can't work.  As was said many 
> years ago "with sufficient thrust, pigs will fly."  But that does not 
> make flying pigs a good thing.
> 

Flying pigs would add RFC 2549 a totally new meaning, incrementing
put through dramatically :)

>>> quite unclear.  The appendix about DSL is not helpful in that regard.

Here in germany DTAG.de, the infrastructure supplier for most aDSL providers
does use PPPoE exclusively, authorization by PAP. It would be nice to
connect an aDSL modem directly to a WLAN and let everybody use his own
personal account via the AP. Alas - eavesdropping ...

If PANA could come in here?

I dont know PANA at all right now. That is why I dont know what harm it does.
Can anybody tell me what to look for?

>> Absent any indication of actual harm that would ensue
>>
>> that there will be multiple solutions seems an inappropriate basis for 
>> denying publication.  (On the other hand, strong indication of 
>> statements about market preferences, which is a small step
>>

There are more complicated protocols that have been implemented, like
netbios over tcp, without thought of their impact on security.

I have burnt my fingers running netbios (samba) on a system (linux) I
deemed imune against hackers. I dont want to run that risk again.

I dont see the pit I might fall in - but I cannot see very far right
now, because of thouse high walls around me :)

Still that is not a reason against documenting it. Just giving more
insight would be welcome.

>> implemented (properly) by virtue of technical errors or documentation 
>> too confusing to understand.  Or cannot be deployed and used, by 
>> virtue of administrative complexity or, again, documentation too 
>> confusing to understand.
>>

Kind regards
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Peter Dambier <[email-masked]>
Date: Fri, 26 May 2006 18:36:36 +0200

> that model no longer applies. 

That is exactly the problem of aDSL here in Germany. The line ends in a
modem at my home and I can connect as many clients as I want, using
different accounts on one ISP or even connect me to different ISPs. So aDSL
here is a many to many connection with people tunneling via PPPoE.

---

From: Peter Dambier <[email-masked]>
Date: Fri, 26 May 2006 18:36:36 +0200

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 10:09:31 -0700

> problem it is solving, then the framework is not doing its job.

As I tried to indicate, any sort of broad-based confusion about the purpose or 
use of a spec is a very basic indication that the spec cannot work.  How can it 
work if the potential adopter community does not know what it is for or how to 
use it?

So I suspect we do NOT disagree on this point.

> there is a need for a new solution.

I enjoy debating preferences and superiority as much as the next IETF attendee, 
but it is not a good basis for rejecting the diligent effort by a chartered 
working group.

Basavaraj Patil wrote:
 > The fact that the IETF is supposed to be based on "Rough consensus and
 > running code" is completely being missed here.

That is clearly not correct.  The nature of Sam's public query is specifically 
(and explicitly) looking for certain kinds of rough consensus.

Currently there are
 > multiple interoperable implementation of the protocol in addition to
 > there existing an open-source implementation as well.
 > The fact that several years of peoples work and effort has gone into
 > this is being ignored by claims that I find quite have a vested
 > interest.

That some people have a common view From [email-masked] Fri May 26 13:16:41 2006
To: Pete Resnick <[email-masked]>
From: Sam Hartman <[email-masked]>
Date: Fri, 26 May 2006 13:12:34 -0400
Cc: [email-masked], [email-masked]
Subject: Re: Comments on draft-iab-rfc-editor: IETF control

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:

    Pete> On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
    >> Ultimately, the rfc-editor function needs to be accountable to
    >> the IETF community because we're the ones paying for it.

    Pete> Sam, I'm sorry, but this is completely unadulterated
    Pete> NONSENSE. Who is this "we" to whom you are referring that is
    Pete> "paying for it"? The IETF folks who happen to go to
    Pete> face-to-face meetings (which isn't nearly everyone in the
    Pete> "IETF community", let alone everyone who gets to publish
    Pete> RFCs) pay enough to cover meeting costs and a part of the
    Pete> secretariat. So the money you are talking about is really
    Pete> ISOC money, and you had better not be claiming that the RFC
    Pete> Editor is accountable to ISOC's corporate sponsors.

We, here, is the set of people collectively who recently decided that
we wanted greater budget accountability and went to a lot of trouble
to form IASA and to start documenting a bunch of informal
arrangements.  As part of that I at least expected to have greater
accountability to the community.  I don't care what community.  I
don't see a difference between IETF, IETF community, Internet
community and rfc-interest community.
I understand some people do.

I do see a huge difference between the IAB and all of the above.  (I
see a huge difference between IESG and all of the above too, if anyone
cares.)

It's fine in my mind if the IAB judges consensus of the community
whatever community that is.

However there needs to be a way for a member of this
community--whatever it is--to make a proposal, to get enough support,
and to have that proposal be adopted.

I.E. it is fine if the IAB of whomever can do a lot of things on their
own.  However the community needs the ability to either guide the IAB
or override the IAB if there is disagreement.

There needs to be a formal process because that's how we get
accountabilitiy.  That process needs to be open and fair.  Open and
fair processes have some dispute resolution/appeal mechanism.

I do not relish the prospect of inventing all that all over again just
for the rfc-editor.  I'd much rather use the heaviest weight process
(publishing a BCP) we have available to us as an override.  I'of the work and that they have used that 
common view to produce interoperable implementations is extremely important. 
However the difference between "a few folks can make this work" and "the 
broad-based Internet technical community can make this work" entails a 
non-trivial aspect of protocol scaling.  Scaling in development and adoption is 
just as important as scaling in use.

d/

m happy
if the last call for such a BCP needs to have input from a broader
community.  I'm happy if the IAB rather than the IESG judges consensus
provided there is an appeals process that involves more than just the
IAB.

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 May 2006 10:09:31 -0700

Currently there are
 > this is being ignored by claims that I find quite have a vested

That some people have a common view of the work and that they have used that 

d/

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 15:11:38 -0700

I, as a PANA WG chair, have many issues with this thread. It's objective,
execution, place in IETF process, roles and responsibilities, etc. I'm not
going to get into that now (yet). But I want to say I don't see how it's
going to achieve what Sam thinks he wants to achieve -- neither the need for
doing that as I explained earlier.

We'll try to weed out the technical and useful stuff out of this jungle. Let
me create separate threads for those and see if we can prevent further
confusion before people confuse each other, and identify what additional
work needs to be done on our documents.

With that in mind, here is the first thread.

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, May 26, 2006 8:05 AM
> To: Alper Yegin
> Cc: 'Bernard Aboba'; [email-masked]

This is not how the NEA charter read (see my above quotes). Where did you
get this idea from? 

> not running at the link layer than why do they want or not want PANA.

This is something that needs to be asked to the NEA community. PANA
community did not invent using PANA for NEA. When NEA people said they
needed IP over UDP, we said PANA does that.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 May 2006 15:14:19 -0700

> problem it is solving, then the framework is not doing its job.

Framework document discusses deployments. Problem statement and requirements
is what you are looking for (RFC 4058).

> place) why there is a need for a new solution.

Again, this is in the scope of the problem statement and requirements. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 May 2006 00:29:39 -0400

Hi Joel,

Thank you for spending your time reading the framework document and
sending your feedback.  Please see my response below.

> be more of a "system" or "solution" document than a clean IETF 

I think your reading is correct.  The document describes how different
types of access network deployments are enabled by PANA.

> 2) Selecting an authorization (charging, possibly packet handling) service

Just to make sure, do you mean by 2) network selection that is
described in Section 8 of pana-framework draft?

> needed, then solve that problem.  

This is surely one problem PANA is trying to solve, and has been
clarified from the beginning of the work and more in this dicussion, I
believe.

> Personally, I would find the work 

Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
from EAP-based network access authentication is another problem.  When
a lower-layer does not provide EAP service, it is clear that PANA is a
standard way to solve the problem.  Perhaps the main confusion is
coming from the fact, as a side effect of solving this bootstrapping
problem, that it is possible to use PANA to bootstrap lower-layer
ciphering *even if the lower-layer supports EAP*.  While I understand
the confusion but let me explain several reasons for why I think this
is still viable for lower-layers that support EAP.

- Use of PANA for bootstrapping IKEv2.  I explained several reasons
for why doing this while IKEv2 can carry EAP, in my response to Vidya:
http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html.

- Use of PANA for bootstrapping IEEE 802.11i PSK mode.  This makes APs
and non-AP STAs that support 802.11i but do not support 802.11r can
transit from one AP to another without necessarily perform EAP for
every AP transition as long as the APs are acting as EPs of the same
PAA.  One may argue that this usage becomes useless when all APs and
non-AP STAs are migrated to 802.11r, but it is still possible to use
PANA for inter-ESS transition which is not covered by 802.11r.

> document is quite unclear.  The appendix about DSL is not helpful in 

One of the reasons for this may be that the problem statement and
requirements are described in a separate RFC (i.e., RFC 4058) not in
the pana-framework draft.  Of course another reason may be that I, the
editor of the draft, am not a native English speaker.

BTW, there is no appendix in pana-dramework draft.  So you may refer
to Section 10.1 about DSL.  Is this correct?

I hope this sheds some light on the discussion.

Yoshihiro Ohba

---

From: Florian Weimer <[email-masked]>
Date: Tue, 30 May 2006 07:49:37 +0200

> that model no longer applies. 

Isn't this just a "don't do that, then" scenario?  Plugging in a hub
tends to undermine much of the accountability 802.1X is supposed to
provide.

Anyway, 802.1X is terminally broken because end users can rewire that
port and bypass security policies (put a laptop with bridging software
onto it, plug in a hub, and so on).  It's very hard to solve this
problem at a sub-IP layer because you need an ARP replacement which is
tied to the port (physical layer) and IP rouuting (network layer) at
the same time, and in a secure fashion.  And without some cryptography
on the payload, you still won't be able to tell two hosts on the same
port apart.

My personal conclusion from this mess is to give up trying to make the
sub-IP layers secure, but start directly at the IP layer.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 May 2006 01:14:16 -0700 (PDT)

> tends to undermine much of the accountability 802.1X is supposed to

Sure, except that the cost of "don't do that" is rather high -- a switch 
port for every host. 

> onto it, plug in a hub, and so on).  

The issue here is not key exchange; it's the lack of data protection.  
IEEE 802.11i derives a unique key per STA MAC, using it to key link 
layer ciphersuites providing encryption/integrity/replay protection, which 
eliminates piggybacking.  Yet it relies on 802.1X.  My understanding is that 
802.1ae/af will also solve the problem, by enabling "virtual ports".  

>It's very hard to solve this problem at a sub-IP layer 

I think the point is that there is a significant need (at least in the 
short term) for a transitional solution.  Enterprise WPA/WPA2 
is being deployed, albeit perhaps more slowly than we'd like.  Moving the 
problem up a layer doesn't really address expense/deployment 
concerns that much, especially since IPsec acceleration chipsets ship in 
much lower volumes than say, chipsets supporting 802.11, 802.3 or other 
link layer technologies. At the end of the day, there is significant 
appeal in being able to roll out solutions that don't require forklift 
upgrades.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 30 May 2006 10:51:55 -0400

Hi Joel,

Reading the entire thread, I think we should seriously consider your
detailed suggestions to improve the PANA framework draft for broader
acceptance in the community.

Thank you,
Yoshihiro Ohba

On Tue, May 30, 2006 at 09:42:25AM -0400, Joel M. Halpern wrote:
> I think the confusion and complexity that I perceive comes from the 
> fact that the framework problem treats all the tasks (user 
> authentication, network selection, and securing the network 
> connection as being of the same significance or same relationship to 
> the solution.
> 
> I think that most of the discussion of IPSec and pre-post PANA 
> addresses does not belong here at all.
> 
> Let me suggest an approach that might simplify and shorten the document:
> [Unfortuantely, I can't promise that it will fix everyone's problems.]
> 
> 2. Describe the primary goal of PANA, and approach thereto.  This 
> would state that the goal is to authenticate the user using an IP 
> level protocol.  This would probably state that the primary approach 
> is to proivde a transport for EAP that meets the requirements for an 
> EAP transport [cite RFC.]
> 
> 3. Describe very briefly the interaction between the EP and the 
> PAA.  State that the protocol between them is out of scope.  Note 
> that the EP must allow PANA messages to the PAA before authentication 
> is completed.  (Yes, that's obvious, but it is actually worth stating.)
> 
> 4. Describe that PANA protocol needs to provide for negotiation of 
> information before authentication.  List briefly some of the things 
> to be negotiated (services available, algorithms available.)  Also 
> indicate that the PANA protocol can provide additional 
> post-authentication information to the client (in the PANA response) 
> and to the EP.
> 
> Securing the data channel between the PCC and the EP should be out of 
> scope.  If you want to say anything about that, you might note that 
> this may be done in a link specific fashion, in may be done with an 
> unauthenticated IP exchange before PANA, or PANA may be used to carry 
> additional credentials / keys to be used to establish an 
> authenticated secure association.  The reason I would not include 
> this is that the question of why I need an authenticated exchange 
> will complicate the document.  The other reason for not describing it 
> is that it does not change the framework at all, and should be 
> documented as a usage of PANA capabilities, in its protocol RFC.
> 
> I would then probably dramatically reduce section 10.  Trying to 
> describe all those cases does not actually help the reader get the 
> mental model.  And I think they are too deployment specific.
> 
> The real key here is to focus on the primary goal.  The resulting 
> document ought to be clearer, and focused on the problem that needs 
> to be solved.  It can indicate that PANA can be used to help other 
> things, but that those things are not the purpose / point of PANA.
> 
> At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote:
> >Hi Joel,
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 May 2006 09:42:25 -0400

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2006 17:28:10 +0200

> acceptance in the community.

Which is strong hint that this discussion now belongs on the PANA
mailing list.

    Brian