[Pana] Draft meeting minutes

See below for the draft meeting minutes from IETF 58 PANA meeting.
Please let us know if there is a need to correct/add anything.

Alper

Protocol for Carrying Authentication for Network Access WG (pana)

Tuesday, November 11 at 0900-1130
==================================

CHAIRS:    
  Basavaraj Patil <Basavaraj.Patil@nokia.com>
  Alper Yegin <alper@docomolabs-usa.com>

Note Takers: Dan Forsberg, Mohan Parthasarathy

AGENDA:

1. Preliminaries (bluesheets, minute takers, agenda bashing): 5 min
   Chairs
--------------------------------------------------------------------

Dan will take minutes.
Mohan will take minutes.

Raj went through the agenda and document statuses.

STATUS of WG I-Ds:

-  draft-ietf-pana-usage-scenarios-06.txt
   WG last call completed on 3/11/03. Draft is sent to ADs for IESG
   consideration.

-  draft-ietf-pana-requirements-07.txt
   WG last call completed on 6/12/03. Draft is sent to ADs for IESG
   consideration.

-  draft-ietf-pana-threats-eval-04.txt
   WG last call completed on 5/1/03. Draft is sent to ADs for IESG
   consideration.

-  draft-ietf-pana-pana-02.txt
   Work in progress. I-D will be discussed at IETF 58.

-  draft-ietf-pana-ipsec-00.txt
   Work in progress. I-D will be discussed at IETF 58.

2. PANA protocol update and open issues: 30 min, Yoshihiro Ohba
--------------------------------------------------------------------

   draft-ietf-pana-pana-02.txt. See "Change History" section of the draft
   for the list of issues closed in this revision. Detailed issue
   descriptions can be found at http://danforsberg.info:8080/pana-issues/
   Newly closed issues and currently open issues will be covered in this
   presentation for confirming/achieving consensus.

Dan: change the URL of open issues on the first slide (take away the
"www").

Closed issues:

Issue22, R-flag is used to distinguish request and answer.
Issue23, shared code space with Diameter.
Issue17, PANA-Error is defined.
Issue24, avp alignment rule is added.
Issue18, PANA-Termination-Cause AVP values are defined.
Issue19, Result-Code AVP values are defined.

Other issues:

Issue20.
Issue25. Relates to ISP selection.
Issue8.
Issue31.
Issue32.
Issue33.
Issues21, 26, 30.

Issue20. Retransmission timers and counters. Two classes for
retransmission values: PANA-PAA-Discover and other messages.

Issue25. Service Profile names. Define two new AVPs. NAP-Information and
ISP-Information AVPs. Defined a new flag (S). F-flag is not needed
anymore. PAA advertises NAPs and ISPs (information AVPs).

Open issues:

Issue34. NAP and ISP authentications. Proposed solution: use single
lifetime (the smallest one). Both NAP and ISP re-authentications happen at
the same time.

Issue37. Unknown realm propagation. Should unknown realm AAA message
routing error be propagated to PaC. Direct interface between PAA and AAA
would be needed.

Alper: Yoshi, do we know how other EAP lower layers behave in this case?
Yoshi: IEEE 802.1x doesn't carry any unknown errors.
Raj: Is it required to use EAP layer? Can't we send unknow error message
through PANA? You need direct interface between PANA and AAA? Or is it an
EAP state machine problem?
Yoshi: EAP state machine doesn't allow this. My opinion is that this
complicates the implementation.
Raj: ok.
Mohan: How can PANA error message communicate this problem?
Raj: You introduce PANA-Error message, why not use that?
Yoshi: We can use PANA-Error message to propagate msg from PAA to PaC. The
problem is between AAA and PAA.
Raj: Does this mean that we need to do enhancement to the AAA spec?
Yoshi: no changes to the spec., but to the API perhaps.
Raj: let's take this into further discussions.

Issue29: EAP Failure and PANA-Bind-Request. Problematic with NAP and ISP
authentication. Single PANA-Termination-Request can't be used. We may want
to change the "bind" to "result". "bind" doesn't make sense to carry EAP-
Failure.

Raj: the consequence of EAP failure is termination of the session. Can we
you use Result-Code in the PANA-Terminatin-Request?
Yoshi: Could you elaborate.
Raj: EAP failure means session termination?
Yoshi: EAP failure doesn't always mean termination of the session.
Sometimes two EAP authentications may occur (NAP and ISP). The two
authentications can be completely independent.

Issue36. Re-authentication race condition. Resolution: PAA can always be
the winner.

Issue35. EP information. Device-Id AVP can have a field to indicate
whether the device belongs to PAA or a separate EP. This AVP is carried in
PANA-Bind-Request.

Yoshi: the format we can discuss on the mailing list.

Issue16. Multihoming support. Same or separate session? This is an
optimization issue. Proposed resolution: more thorough analysis needed.
Until the analysis is done, separation is enough.

Alper: I agree with the proposed resolution. How we bind the device id to
the pana session. We need a good analysis on this and we should look on
the impact on the base design.
Mohan: How 802.11 does handle this?
Yoshi: separate session if the mac address is different. 802.1x doesn't
use the term session.

Issue12: authentication in ad-hoc network scenario. Should PANA support
ad-hoc network scenario where there can be multiple untrusted nodes in
between PaC and PAA.

Hannes: we did an experimental of this. This is not a request to do
additional requirements, but possibility.

Yoshi: How does the PaC find the PAA?
Hannes: uses concept from RSVP, router alert option. So it would find the
path to the internet and hit

Thomas: how is this different to the scenario to the scenario where other
nodes can interfere to the communicates?
Hannes: different mechanism is the discovery mechanism. This would work
only if you would start IPSec.
Raj: other requirements say that PaC and PAA must be on the first IP hop.
Thomas: are the intermediate nodes ip nodes or l2 nodes?
Hannes: ip nodes. We wanted to show the possibilities and results of our
experiment.
Thomas: if this is out of the scope, why we have this conversation at all.

Issue2. Downgrading protection. This is an EAP problem. Use EAP-GSSAPI to
negotiate EAP in secure way.

Hannes: we should leave this to the EAP, since this is not a PANA issue.

Alper: let's send these open issues to the list. Follow up on the discussion
on the mailing list.

3. PAA-to-EP protocol considerations: 15 min, Yacine El Mghazli
--------------------------------------------------------------------

   draft-yacine-pana-paa2ep-prot-eval-00.txt. The objective is to gauge
   consensus of the WG on the selection of the PAA2EP protocol as proposed
   in this I-D. Furthermore, solution-oriented discussions will take place
   based on this proposal (I-D: TBD).

Overview.

PANA Terminology. EP is in charge to do the access control and enforce
packet filters. DI and optionally cryptographic keys may be provided by
the PAA to the EP.

Discussion objective. Objective today: gauge consensus of the WG on the
selection of the PAA_2-EP protocol as proposed in draft-yacine...

PAA-2-EP protocol requirements. Secure communication. One-to-many paa-ep
relation. Access control information. PAA initiated communication. New
pac notification to the paa.

PAA-2-EP protocol evaluation summary. The requirements are soft enough.
SNMP. COPS-PR. NetConf. Other immature solutions (Diameter, Radius, ForCES).

SNMP applicability against the PAA-2-EP Reqs.

SNMP applicability re-usable existing MIB objects.

SNMP applicability additional PANA-specific MIP specs.

Next steps. Selection of the PAA-2-EP protocol. SNMP? Either annex to the
PANA protocol draft or into a new wg document.

Alper: proposal is to use SNMP. Any feedback?
Mohan: we need new MIB variables to the existing? How do we do this?
Yacine: some additional objects can be seen as an extension.
Yoshi: using snmp is coming from MIDCOM. I'm not sure if this is
applicable to PANA. Relates also to accounting. If accouting period is
shorter, it is difficult to support this scenario.
Yacine: snmp doesn't provide accounting stuff. These mentioned issues are
not in the requirements draft.
Yoshi: it is ok to mandante snmp, but we should allow other too.
Yacine: the wg should just mandate one.
Raj: is there any reason to rule out diameter, radius? Provides more
functionality and accounting.
Yacine: may provide much more functionality in some cases, but my
understanding for pana needs are that req are soft enough to allow any
protocol. My understanding is that pana needs right now a working
solution.
Raj: I accept that an AP may not have diameter or cops.
Raj: you should also look the work in the nsis wg. We should ask consensus
and maybe take to the mailing list.
Raj: PAA-2-EP protocol. is snmp sufficient for EP-2-PAA protocol?
Alper: how many have read the draft? Around 7. We need more than this for
voting.
Raj: back to the mailing list.
Alper: Yes.

4. PANA-IPsec I-D update: 10 min, Mohan Parthasarathy
--------------------------------------------------------------------

   draft-ietf-pana-ipsec-00.txt. Objective is to discuss the latest
   changes (see Revision Log) and confirm consensus.

Mohan: this was presented in the last ietf.

Open issues. Use of Ipsec tunnel mode instead of transport mode. Pre-
shared key derivation for ike.

Hannes: the draft is very generic. So this is just fine.

Open issues contd. What to do if msk is updated because of re-
authentication. 

Raj: you get the msk of the resulf ot eap. How does the ike take the key?
Mohan: pre-shared key into the file. Discussed already on the mailing
list.
Hannes: several issues. API issue. Key naming, which is confusing. It says
that which SA you select. Another is the lifetime. Not only the MSK, but
also authorization parameters. You have to make that these are in sync. If
new msk is generated some authorizations may have been changed and the ep
should know about these.
Thomas: some people familiar with ike have raised issues. Security
properties. We need to think more about this. Careful analysis required.
Talk to Bernard Aboba.
Mohan: ike is exactly the same as in 802.11.
Thomas: same concerns. Be careful.
Alper: we should check keying framework draft. Key naming issue is
important for this point. With new msks we get new key names. With option2
we need to differentiate the previous and the new key. We might end up
with a key number. Keys are changed inside the one session. Maybe we need
an additional attribute to identify the key.

5. PANA state machine considerations: 20 min, Dan Forsberg
--------------------------------------------------------------------

   The discussions will be based on the state machine diagrams provided at
   http://danforsberg.info:8080/pana-issues/issue28.

Thomas: How many people read the state machine? (7 or so hands). Not many
Raj : Has been around for sometime. There has not been feedback on the
state machine draft itself. Need feedback. Should it be part of the
protocol solution or a separate document ?

Not very many folks have read the state machine draft.

6. Unspecified source address discussion: 10min, Chairs
--------------------------------------------------------------------

Charter change was requested for the ADs. ADs came back with some concerns
about this issue. Some discussions on the mailing list. Current state is
to allow the use of unspecified IP address.

Thomas: This chart is a bit misleading. Today the clients try the dhcp
first. If no dhcp response, allows link-local addresses.
Alper: We are not changing that. If deployment wants to do PANA, then
the network will not respond to DHCP and start PANA.
Thomas: you make an assumption that all clients are updated to use pana.
Alper: Obviously.
Raj: We didn't change the client behaviour. We are thinking about using
link local address.
Steve Bellovin: my concern is the concern on the ip stack. This dhcp
behaviour is embedded in a lot of code. There are lot of stacks. This is
an attempt to reverse the decision that was made before.

Thomas: brings to my mind. The existing specs may suggest that the
unspecified address is meant to be used only as a source address.
Steve: also the case that there are a lot of filters. This behaviour is
blocked. I'm concerned about host stacks.
Vijay: There is another place where unspecified source address is used.
IPv6 duplicate address detection. If this is restricted on link, we should
be able to use.

Ralph: what will this first bullet mean?
Alper: default host behaviour is that the client will use dhcp address
configuration. If it fails, host uses link local.

Why allow unspecified PaC address. Address depletion attack. Dad attack.

James Kempf: Don't use unspecified address. Use the proposed CGA address.
You are shifting the dos attack from dhcp to the pac. One can blast the
network with packets.
Alper: that would be a different type of dos attack.
Kempf: I meant paa, I'm sorry. You're sifting the problem around, but not
solving it. The fact is that you can't secure the link configuration.
Alper: its hard to prevent all dos attacks.
Raj: the thread analysis document talks about this.
Kempf: if you have address you can more easily do the dos.
Alper: no, then the client is already authenticated at that point.

How does authentication first giving ip address later help? Attacker
identification. Ipsec based access control. Still need secure dad. PANA SA
might help SEND. No straight forward benefit of configuring IP after PANA
if IPsec-based access control is used.

Utility of handling this threat. Does handling this dos threat improve the
overall security (how about other dos attacks)?

Deployment considerations. In some scenarios, final address assignment
depend
on the client id. Pre-pana address, post-pana address. Address management
with ipsec.

Drawbacks. Sending to unspecified ip address. Receiving from unspecified ip
address. Fragmentation.

Mark Stapp: my question is about existing stacks. Somehow the pana client
has to have a configuration in relation to the ipsec. If it is needed or
not. If dhcp is in progress. This sounds very complicated (entangled).

Pete McCann: in existing deployments today we have good cryptography on
existing l2. this is why we need pana. Hardware hackers. There are fixes
to fix ip layer to the mac layer. Its always good to check the mac
address. This doesn't fix the problem. I still want to see the mac
address.

Thomas: 2 points. 1. I disagree with your summary. It is biased. Couple of
examples. Fragmentation is not that black and white. Yes, you can disable
the IP level fragmentation. Eap methods doing the fragmentation has a
cost. This leads to a lot of round trips and delays. The performance is
not acceptable. go back to the send slide. I think this is an open
question if this can be solved by SEND in pana context. Whether send can
deal with this or not is an open issue. 2nd point. If there is a need for
pana to be able to do some exchanges prior to address assignment. You need
to select the isp and then this isp gives the address. I understand this
but this is really different than the dos attack scope.
Alper: there are two issues. Security and deployment and they are
orthogonal to each other.
Thomas: you need to be careful with the requirements.
Alper: yes, there are two different issues here.

Kempf: send may be able to solve DAD issue. But not with unspecified
address. Using pana for enabling send is speculative at this point.
Don't base your design on that. What is the problem with configuring
link-local always and disabling dhcp?
Thomas: you are changing the default host behaviour. Does not work if
there is no PANA.
Alper: we can do that only when we have a full control of the network,
then we can make such asumptions. Preconfiguration: do pana first.

Kempf: What is the problem with link-locals?
Alper: security is the issue.
Pete: I still have to check the mac address in the receiver and while
sending. This doesn't really seem to solve the problem.

Alper: you can send to link-layer destination or use the broadcast.
Alper: if the client is using unspecified address, whether the packet
is sent to link-layer destination or broadcast is implementation specific.

Thomas: client needs to choose an id.
Alper: session id chosen by the paa and it's unique.
Thomas: We have a bootstrapping problem.
Alper: we may need to send another id from client to the paa. So that the
paa can differentiate the address.
Thomas: this is solvable, but do we want to go into this direction at all?

Mark Stapp: We can't trust dad, dhcp, we still need to have this mac
checking.
Ralph: we can't solve the problem with pana. For example: The use of
unspec address with dhcp. You mentioned that authenticated dhcp would
solve the dos. 
Alper: the dad must be secured even when dhcp is used, otherwise we are
not solving the problem.
Ralph: we have technology available today that some platforms combine
dhcp with arp processing for arp security.
Alper: not familiar, can you send the info please.

Ralph: I'm wondering about the deployment scenario for post-pana address
case. We do that today. Post-address authentication. How is this mechanism
improving this?
Alper. Referring to? Allocation of pre-pana and post-pana addresses is
doable today. It's the question about the additional cost.
Ralph: if 802.1x is the scenario. Can we require this to avoid these
problems?
Alper: you can do that.

Mohan: what is the cost of using link-local ipv4 address?
Alper: without this we could just say that use pana. But if we assume that
the client has an ip address first, we have to say that you are using
link-locals on the client or you have to have a dhcp server on the access
network.
Thomas: I have problems of understanding this argument. Its too expensive
of having dhcp server?
Alper: It is an additional, non-zero, cost. Normally a NAP hosts a
dhcp relay. Dhcp servers are at the ISP sites. Now the NAP will need to
have a dhcp server and an address pool of its own.
Raj: If you want to run pana you would need dhcp on the access link.
Ralph: an additional dhcp server on the access link. Each of the backend
providers are running separate dhcp server.
Thomas: we can migrate pools of addresses to the access link. The problem
is which addresses belong to which isp.

Question to the WG: do we want to keep allowing use of unspecified ip
address by pacs? Do we want to assume pac always has an ip address?

Mohan: isn't using link-local addresses just fine?
Alper: This could be the case.
Thomas: the problem is that if the spec allows unspecified addresses, we
have to work all the details and put that on the spec.
Raj: It implies that the client has to support both.
Alper: we can follow what dhcp did. We have session-id to support this. I
don't see any difficulties in the protocol design.
Steve: Secure link local address. This is previously unresolved problem.
Basically the client stack vendors would go all the pain of implementing
this. Or the clients do not support it, which in case the operators can't
use this. Making this optional is not a choice. How long does it take to
have this deployed into the hundred of thousands of machines. This is not
possible. Maybe 8 years.
Alper: We will talk about implementations.
Raj: I agree with you steve.
Alper: The question is if we want to have this optional.
Steve: I don't know what benefits there are in this unspec address option.
Raj: How many think that unspecified address support is useful? Vote.
(alper has results). 7 yes, 13 no.
Ralph: Are these questions "either-or"?
Alper: Exclusive. Whether we support this or not.
Alper: Not clear consensus.
Thomas: there are real issues here, but we have to figure them out.
Raj: If there is a consensus that we don't use this option, maybe in the
future we may extend pana.
Thomas: You seem to be concerned that giving the address first has issues.
But there are many other dos attacks too.
Mark: Just moving the dos attack somewhere else.
Greg: we can solve this on pana discovery phase. Don't wait pana to do
this. Make sure you have the base draft out.
Thomas: Isp selection issue. Can pana along solve this? We have to see if
this solution is usable in the context. Service selection, traffic
identification need to be explored.

Thomas: I suggest we go with the current charter. We need to tease out the
issue. We might find a middle ground.
Raj: Rough consensus. Go forward with assuming that pac has an ip address.

7. Implementation report: 10 min, Victor Fajardo; 10 min, Hannes Tschofenig
--------------------------------------------------------------------

   Reports from people who have been implementing the PANA specification.
   The former implementation was recently published at
   http://www.opendiameter.org/

Victor fajardo. C++, lgpl, os: linux, windows xp. Diameter and eap
implementations are also awailable.

Functional architecture. Defines pana api. Independent of eap
implementation. Abstracted transport model. Dictionary-based message
processing.

API. Core object instances. Session based pac and paa objects.

Victor: PANA state machine is helpful, but additional documentation is
needed.

Transport model. Ip stack bypass.

PAA architecture.

Future plans.

Hannes: I will post my slides to the mailing list.

8. Next steps: 5 min, Chairs/Ads
--------------------------------------------------------------------

pana state machine discussions will take place.
We'll have a security review.
Paa-to-ep provisioning protocol details will be worked out.

Alper. Thanks, see you in korea.

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana