Protocol for Carrying Authentication for Network Access WG (pana)
Tuesday, November 11 at 0900-1130
==================================
CHAIRS:
Basavaraj Patil
Alper Yegin
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
--------------------------------------------------------------------
raft-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.
Greg Daley: there's no problem using SNMP for config and something else for accounting.
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.
|
