Subject: IETF 54 meeting minutes

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 1 Aug 2002 12:04:28 -0700

This is the PANA meeting minutes from IETF54. 
Thanks to T.J. Kniveton for taking these notes.

alper

----------------------8<---------------------------

PANA Meeting Minutes
IETF 54
July 15, 15:30-17:30
Note taker: T.J. Kniveton/Nokia
WG Chairs: Basavaraj Patil and Alper Yegin

Basavaraj:
Presented the agenda.
Goal of today's meeting is to go over enhancements to the charter and
to talk about revised requirements, Scenarios where PANA can or may be
applied, and then what kind of issues will a PANA solution have to
deal with.

Most questions about the nature of PANA are answered in the FAQ
written after the last IETF. The URL is in the presentation.

---

Charter issues dealt with since IETF53:
At last IETF, many questions about objectives, which were dealt with on
the mailing list.

- Should PANA access agent and enforcement point be colocated? If not, a
subsequent protocol would be needed.
  - discussion concluded that PAA and EP should be colocated.
- Location of PAA? can it be located beyond the first hop router or point
of attachement?
  - PAA must be located on the same IP subnet/link as the PaC (i.e. first
hop router or even AP)
- PAA is not enforcement entity for access control
  - Just an interface to backed AAA infrastructure
  - Can communicate with EP which may be AR/AP
- IP address assignment- what is role? There was a lot of discussion about
this on mailing list
  - Conclusion: Node must have an IP address before PANA messaging occurs.
- Is PANA required when you have 802.1x or PPP available
  - PANA does not necessarily compete with these, depending on scenario.
  - PANA is L2 independent for access authentication
- Many security issues are still remaining
  - Session hijacking, protection of packets, other open issues.

Outcome of discussion
  - Revised charter, with narrower focus and clear goal. ADs reviewed;
awaiting IESG approval.

Questions?
<Charlie> Is this URL right? (http://www.toshiba.com/tari/pana-charter.txt)
<Basavaraj> Try it again.

--
Requirements and Terminology - Alper Yegin

- Reynaldo Penno is editor of this document now, but couldn't attend this
IETF.
- Authentication Protocol
  - Goal is not to invent a new protocol. Current thinking is that EAP
should be sufficient.
  - If extensions to EAP needed PANA WG will define requirements, not
solutions. Will take these to EAP group or elsewhere to satisfy needs on
PANA
- Device Identifier needs to be integrity protected in PANA request sent by
PaC
  - EAP doesn't do that, but do we really need this?
    - If per-packet auth encryption not used, spoofing can happen anytime.
    - Otherwise, checking DI is redundant
<Hesham> Maybe you can make this dependent on upgrading the encryption

- PAA and EP: PAA needs to communicate filters etc. to EP
- PAA and EP are colocated. Anything else is outside scope
- PAA generally on first-hop router. Requires discovery mechanism for
client.

<Erik N.> Question on previous slide. Popping up a couple levels, I think
there might be different threats, in which case different solutions might
make sense. I think this needs to be written down somewhere in a document
-- threat analysis. A possibility is that you authenticate security, but
allow people to steal somebody else's authenticated service. So a cleartext
DI that anyone else can spoof is sufficient. As long as you're there,
somebody can spoof your DI; that might be acceptible tradeoff.
<Alper> We should have a threat analysis document.

- IP address configuration
  - Must have IP address first. DHCP, autoconfig, etc. Could be temporary
address, or keep using it after PANA.

- Heartbeat: required for links that do not provide disconnect indication.
Optional usage.
- Comments?

<Steve Deering> What is timescale of heartbeat? I'm thinking there are
already effectively mechanisms: lease for DHCP, IPv6 addresses can be
advertised with lifetimes, does mobile IP already have requirement for
frequent-enough messages? Is this high frequency - every 1-10 seconds?
<Basavaraj> Intention is for disconnect indication. Depending on type of
link, every 2 seconds. If nothing else will provide, then it's there.
<Alper> Purpose is to detect when client leaves network to prevent
hijacking
<Hesham> Time-based charging might be another reason
<Steve> So you're wise not to send this thing

<unknown> About heartbeat, is it between client and PAA?
<Alper> Yes. It's between the PANA end points, that is PaC and PAA. It's
not between PaC and EP.
<unknown>Right, but assumption is they're (EP and PAA) colocated.

<unknown> Could lead to denial of service
<Basavaraj> Security implications of doing authentication at L3 is
something we need to consider

<Deering> Hope you're sending it as a link-local multicast, to survive
failure of PANA client
<Basavaraj> You're suggesting solution of how to implement this.

<Derek Atkins - Security area> Heartbeats/Keepalives turn into make-deads.
If there is congestion, keepalives may get dropped and your network
connection disappears. If you bill per time, you just reauthenticate every
per-time period. I recommend getting rid of heartbeats completely.

<steve deering> My question was more generic requirements. Do you need to
support multiple PAAs
<Alper> Network supports multiple access routers. And there can be several
authentication agents on the network.

<Thomas Narten> You're making assumption that PAA and enforcement pt are
colocated. But if there are 2 routers, and you want to switch routers, you
need communication between routers to support this. Can we safely say that
PAA and EP are colocated? Doesn't sidestep original problem.
Also, is heartbeat wrong terminology? This is really a re-authentication
<Alper> Well we also have re-authentication. So let's reconsider the
current setup, might be too much.

<Erik> If heartbeat is there to determine when to stop billing, you need to
protect against someone pretending to be the guy who just left, which
sounds like you need reauthentication.

<Unknown> Are you trying to handle case where you have an ad-hoc network
accessing managed network?
<Alper> Authentication agent multiple hops away is out of scope.
<Narten> Wouldn't it just get a managed addresss?
<Deering> Alternative scenario, router part of MANET who is next to AR is
the one who asks, rather than expecting node multiple hops back

<Mike St.Johns> This is supposed to be a generic protocol supporting
someone plugging into a wire, right? So if we find a generic situation
which I can implement in all situations, then there is no reason to
implement this.
<Erik> Even if the problem is solved by this protocol, there is nothing to
prevent neighbors from just stringing ethernet wires.
We've talked about this as being generic, but it's unclear this provides
the mechanism we're talking about because it won't work in all situations.
<unknown2> If this locks me down to one address, this means that I can't
use privacy extensions in v6
<unknown1> Cable modem systems let anybody come on
<unknown3> This is a topical question with Time Warner sending out letters
to people using 802.11. We need to move to a model where if you use an
excessive amount of bandwidth, you pay for it. If I am sharing my
connection with 100 people, I am doing a service by reselling the bandwidth
<Erik> we can have a good discussion if we have something written down.
<Mike St. Johns> If it's trivial to bypass authentication (i.e. friend is
on same layer 2 access network), this protocol doesn't do anything to
improve that process. If we have a hole in the process, we need to
understand what we're actually getting from this protocol.

<Unknown> Question on different topic. If you have public shared hotspot,
PAA will be managed separately by operators, but EP might have to be on a
separate device.
<Basavaraj> PAA addressible by separate addresses. But IP's can be
colocated on same box
<Alper> PAA on EP, and only on backend, requests are forwarded to different
AAA servers.
<Unknown> EP could just forward directly then. Proxy functionality. What is
the definition of PAA then?
<Alper> Functionality is PANA endpoint. PANA is front end to authentication
protocol.

<Unknown> Getting IP address first -- is it possible to run pana coincident
with DHCP so that you don't get an address if auth fails?
<Basavaraj> in terms of simplification, we have concluded that it has to
have an IP address.

<Unknown> Suggestion of additional simplification. If we can have access to
multiple PEs, why not require unique relationship with EPs? If I have
access to more than one EP, I have to establish unique relationship with
PAA.
<Narten> So client interacts with each PAA and run PANA with both of them?
Yes. Then you can require PAAs to talk to each other.

<Unknown> PaC's may be able to communicate with each other, and
authentication between them may be important in ad-hoc networks
<Basavaraj> Please write up this scenario and post to the list.

<Gopal Dommety> Do we really need IP addresses?
<Basavaraj> Check the list for this discussion. After PANA happens, there
may be a new IP address, or characteristics of IP address then change.
<Erik> We tried to restrict this to have colocation, and IP address. But we
could expand this stuff if there is a good reason to. 6 months ago this was
nebulous and it wasn't clear how to find a solution. So this is part of a
focusing effort but scope is not closed forever. But whomever wants a
larger scope

<Jarno R.> Was IP issue decided before or after colocation issue? Many
problems with unspecified addresses if colocation is not there, but
otherwise.
<Basavaraj> Discussion was done after colocation of PAA and EP.

---

Usage scenarios
Yashiro Ohba

- Mobile IPv6, CDMA 2000, DSL/Cable modem, Limited scope access network
- MIPv6
<Steve Deering> Why is mobile IP relevant here? The PaC is asking for
access to the internet. Once it gets it, it will use it to do a binding
update. But i don't understand why this is specifically motivated by mobile
ip.
<Basavaraj> Earlier in MIPv4, you have a FA where we show PAA. To a certain
degree, it does authentication. So FA was essentially performing role of
PAA. But even if you're not doing MIPv6, your point is still valid.
<Hesham> This is important, because you don't want to confuse sending AAA
messages with sending mobility signaling. You could replace sending MIPv6
with sending HTTP.

- Multi-layer authentication. In CDMA2000, server system authentication and
then higher layer authentication (PPP/Mobile IP)
- PANA can be used for authentication in the case of Simple IP service in
lieu of PPP.

- DSL - PANA works in any topology
<Unknown> in DSL modem or customer premise equip, there may be a router.
Can we use this scenario?
<Ohba> In that case, the router functionality is combined in DSL modem. So
home router can be PaC on behalf of client behind home router.
<unknown> How about guest?
<Basavaraj> You're basically creating an access network at home, and could
use a PAA there.

<Gopal> Does PANA allow for authentication of services? For example, 802.1x
does not have that capability.
<Basavaraj> We did discuss this to a certain extent on the mailing list.

- Last scenario: limited scope access networks (original scenario).
- Limited scope access is unrestricted. Then access to internet requires
PANA authentication

<Unknown> Who initiates the authentication
<Ohba> We'll discuss this during the solution issues presentation later.

- Example: local web server can be accessed without authentication

<Deering> Local free services are on other side of PAA (not on same subnet
as host). That's where it gets interesting. I.e. you might have a router
between the PaC's and services.

<Mark Townsley> DSL uses PPPoE and PPPoA, which assign addresses after
authentication. Actually this is a requirement.
<Narten> issues of migrating away from PPP are pretty big. Whether to use
PANA are at most 10% of the problems there so let's not use it as a
justification. This scenario is not realistic, but wishful thinking in some
sense.

<Unknown> Could I authenticate a machine, then authenticate a user? Like
what exactly am I authorizing? Is there a way to do layered authentication?
<Alper> A client is authenticated, and credentials are supplied by the
client. Network access is authorized to the device being used by the
client.
<Basavaraj> You could authenticate at layer 2, and then authenticate the
user at a higher layer (PANA). But not in the scope to use PANA to control
the scope.
<Deering> The service being authorized is being able to send and receive
packets to an IP address. And if the packets don't carry user info, talking
about user authentication doesn't make sense. The service is the ability of
the wire to emit and receive packets.

---

Issues w.r.t protocol solution

- UDP/ICMP/IP?
- What would be PANA based on to encapsulate EAP?

<Hesham> What about a connection-oriented protocol?
<Pascal> SCTP allows you to do partial reliability
<Narten> Are you suggesting SCTP ought to be a candidate?

<TJ> What about using ICMP embedded data option?
<Alper> It may be difficult to get ICMP #, and requires IP stack changes
<TJ> OK, IP stack is going to need to be changed to implement this anyway.

<Unknown> PANA + IPsec differ remarkably from PPPoE.
<Alper> There is physical protection (unshared medium). Can just use PANA.
CDMA2000 has L2 protection. If no other protection, PANA might be used in
conjunction with IPsec.

<Gopal> What is identity? We don't have an IP address, and MAC address can
be spoofed
<Alper> you may have to rely on IPsec and use IP address as identity.
<Deering> IPsec would solve the problem but the overhead is high. Might
want to use ESP and AH to remote place; generating separate signature and
sending in packets seems to be a non-starter
<Pete McCann> NAI is right id to use. IMSI is going to go away eventually.
Distribute keys down to layer 2.

<Unknown> Authenticating machine and getting access vs. auth user. So we
are talking about multi-layer auth.
<Basavaraj> Device identifier - MAC address.
<Unknown2> IMSI or ESN is tied to subscriber record somewhere.
<Deering> Credentials presented are who is it that's going to be billed?
Doesn't say anything about multiple users and which ones are authorized to
send packets.

<Unknown> IMSI is only pointer to HLR/VLR or AC used today. When you talk
about NAI, that's more meaningful for AAA server, which gets involved later
on. It is really an architecture issue to bring these two together.

<Erik> Steve's comment - you could use IPsec. Well PaC could just be router
at your house; might not know how to map to users
<Deering> You can get arbitrarily fancy with the granularity. The packets
might be signed with the right thing to make your PAA happy.
<Erik> But tagging mechanism might not extend beyond the enforcement. So
cases where it works are more limited.

- How does PaC discover PAA?
- What would heartbeat method be?
  - According to earlier discussion, additional mechanism might not be
necessary

<Deering> I hope there will still be networks that allow you to get to the
net without presenting your credit card. If you are doing a solicitaiton
mode on every network they attach to, well I prefer the model where in v6
the RA would include a flag saying to get beyond me, you need to include
some PANA info.

- How will PANA be triggered when PaC goes beyond "free zone"?
- PAA sends ICMP error message, sends PANA Start message, ..can PaC know on
its own to send PANA start?

<Gopal> Why are we saying two services? We should talk about service
authentication in a full blown way or not talk about it at all.
<Basavaraj> The question is what should trigger PANA to occur?

- New IP address assignment after PANA. Reasons:
  - Another IP address with greater scope (link local vs. global)
  - Might want to obtain provider-specific IP address
- How is it done?
  - PaC decision (policy)
  - PANA success message can have a bit to get a new address
  - Router colocated with PAA can take an action

<Mark Townsley> PANA message with this bit contradicts with the
FAQ (PANA does not do address allocation)
<Alper> It doesn't really do address allocation, it just indicates
PaC should do it.

<Narten> Is this a decision that's been made, to get a new IP address, or
just a possibility?
<Unknown> Changing IP address on the fly might be asking a lot from the
client stack

- How do we secure protection against eavesdropping and spoofing?
  - PANA can recommend using specific EAP methods when underlying medium is
not secure.

<Narten> PANA should pick another scheme rather than developing its own.

- If there are multiple first-hop routers, how does PANA work?
  - Each router has a PAA and responds to discoveryPaC does pana with all
  - Each router has a PAA, each PAA responds, PaC does pana with one
  - Only one router has PAA

-Questions?
<Erik> Last slide seemed to say that in some cases, you need a protocol to
carry things between PAA and enforcement point. Maybe WG needs to put that
in the charter to pick one protocol to use to do that. It might be too
constraining to say that you can always colocate these, even when you have
multiple ARs. Then the scope expands to pick a protocol to carry this
stuff.
<Deering> Just choose step 1, and PaC does pana with all of them.

---

Next step: get feedback from IESG on charter and update charter.