quicker.Protocol for Carrying Authentication for Network Access (PANA) WG
Meeting MinutesSession: Monday, July 14 at 1300-1500Chairs: Basavaraj Patil
<Basavaraj.Patil@nokia.com> Alper Yegin <alper@docomolabs-usa.com>Note Takers: Jayshree Bharatia, Paulo PagliusiTopic 1. Draft Status
----------------------------------------
---------------------------------Short discussion on the current document status was given by the AlperYegin.- draft-ietf-pana-usage-scenarios-06.txt WG last call completed on March 11, 2003. Draft is sent to ADs for IESG
consideration.- draft-ietf-pana-requirements-07.txt WG last call completed on June 12, 2003. Draft is sent to ADs for IESG
consideration.- draft-ietf-pana-threats-eval-04.txt WG last call completed on May 1, 2003. Draft is sent to ADs for IESG
consideration.- draft-ietf-pana-pana-01.txt Work in progress. The draft will be discussed at IETF 57.Topic 2- Securing the first hop in PANA using IPsec by Hannes
Tschofenig
----------------------------------------
---------------------------------The intent of the draft was discussed in brief. This draft provides a
mechanism for enabling IPsec-based per-packet authentication between the PaC
and EP, once the client is authenticated by using PANA. IKE
pre-shared key is derived from the PANA SA, which is established when PaC
and PAA authenticate to each other. Pre-shared key is derived from the
PANA SA. It was mentioned that manual key distribution is not used. Main
mode and aggressive mode are easily supported. There may not be any
issues for IPv4. For IPv6, the router and neighbor discovery related
extensions are different. Also, the initial problem may be that IPSec
selector can't be used as a traffic selector. All packets are tunneled to
the link local address of the EP. The packets are protected twice, for
local and the remote networks. IKE pre-shared key derivation is done from
the PANA security association. The recommendation was to use the IPSec
tunnel mode instead of the IP-IP Transport mode.Hesham Soliman - The problem of the selector seems like the
implementation problem which may be solvable. This comments was revised
later in the discussion based on the different understanding.? - It is necessary for PANA WG to contact IPSec WG for solution of the
selector problem. Keys are for the bootstrapping IKE. If this is the case
than it will be more complicated.James Kempf - If PANA is already solving the PAA and host(MN) security
problem, why it is necessary to have IKE exchanges?Alper Yegin - The current mechanism allows binding of the client ID to the
data traffic. The PANA association is not exactly the IPSec
association. There needs to be some kind of binding between them.James Kempf - Can't we just carry EAP inside IKEv2?Alper Yegin - Are you suggesting replacing PANA with IKEv2?James Kempf - No, run IKEv2 independent of and after PANA.Alper Yegin - Let's take this offline and discuss on the PANA mailing
list.Brijesh Kumar - I am not convinced that the mechanism described in this
particular I-D is useful, since link layer security mechanism already
provides enough security. There is no need to run IPsec twice on a single
client.? - The end points are different and they provide different level of
security. The safe assumption here is that there may not be security
support at the layer 2.Chairs did a consensus call on whether or not to adapt this
individual submission as an official WG item, given that the WG had
already agreed to tackle this problem space. 15 people said agreed, 5
disagreed to the adoption of this draft.Conclusion: There is consensus on the adoption of this draft as an
official WG item.Topic 3. PAA-EP Protocol Considerations: By Yacine El Mghazli
----------------------------------------
---------------------------------- Terminology like PAA, PaC, EP were discussed in brief along with the
scenario description of PAA/EP separation (when PAA separated from AR and
also when PAA co-located with AR.- The following PAA-EP Protocol Requirements were mentioned. The details of
these requirements are noted at
http://yacine.free.fr/ie
tf/draft-yacine-pana-paa-ep-reqs.txt. a. Discussion objectives - No new PANA protocol design - Use of existing protocol b. Core Requirements - pana-req-07 document is used as a base - Secure - one-many PAA-EP relationship - Provisioned data c. Nice to have functionality - Pull model - Inactive peer detection - recovery- The Protocol Comparison discussion included comparison of SNMP,
COPS-PR, DIAMTER and ForCES protocols. 1. SNMP Applicability: Description on how SNMP satisfies the current
requirements and also few pros and cons are discussed. 2. COPS-PR: Same as SNMP, it satisfies most of the requirements but
seems like having more advantages. 3. DIAMETER: It satisfies all requirements but not meant to be used for
provisioning. 4. ForCES: This protocol is still being discussed. Otherwise seems like
satisfying most of the requirements.Gabriel Montenegro - What is the relationship between this subject and
CAPWAP (BOF)?Alper Yegin - This is about provisioning, and it is not PANA protocol.
CAPWAP has also some aspects of this. This is a good question, let's ask it
at CAPWAP meeting as well.Ralph Droms - What about NETCONF as another PAA-EP protocol
candidate?Alper Yegin - Sure, we should look at that too.Reinaldo Penno - Let's do not waste too much time in the Protocol
evaluation process. Let's make it quick and simple.Conclusion:The topic is still open to the discussion. There may be a need of
coordination with other IETF work groups like netconf.Topic 4. PANA Discussion and Open Issues:
----------------------------------------
---------------------------------The list of PANA issues can be found at
http://danforsberg.info:8080/pana-issues/.Issue 9:Issue: Message format not defined in the 00 draftProposed solution: Diameter-like message format is suggested to be used
(header+AVP)Issues 4,5,16: 1. Device ID needs to be updated Proposal is to use Re-auth command which contains new device ID. 2. MAC and IP address are used at the same time Couple of proposals are discussed: Support either MAC or IP address as
DI and not both addresses at the same time or use both addresses
(assuming that SEND will solve the issue). Alper Yegin - Is it really useful to bootstrap 2 layers of
ciphering? Pasi Eronen - Both L2 and L3 may be useful, 3GPP does that. Alper Yegin - What is the purpose of two layers of ciphering in 3GPP? Pasi Eronen - One for the local access, one for the remote access to
home domain. John Vollbrecht - Is this same as EAP with MASTER KEY and Multiple
Session Keys? Alper Yegin - Yes, it is. 3. In single Device ID, use multiple IP addresses. PaC can have multiple IP addresses on the same interface. This may not
be issue since it is not required to have different interfaces
specified for all IP address, Is this sufficient or is there any need of
mentioning all IP addresses as DI and bind to session. Melinda Shore - Why do we use DI in PANA (regarding the use of
addresses as identifiers)? Alper Yegin - We need it to bind the authenticated client to its
associated data traffic. ? - Change of address in the middle of session should be looked at as
well. Ralph Droms - What is the impact of IPv6 privacy addresses on DI? Alper Yegin - Generally link-local IPv6 address is used as Device ID.
Hence, if the inner IP address change, there shouldn't be any problem.Issue 6:How can a PANA session identified? The proposal was to use new
session-Id.Issue 3:New section is added to the document describing PANA security
association establishment (section 5.0).Issue 8:The discussion took place on what parameter should PAA communicate to
perform re-authentication. Session lifetime and Refresh interval were
mentioned.Issue 11:For the PANA client notification, the author added new section 4.10. Also,
PAA-EP protocol is evolved to solve this problem.Issue 7:Moving context from one PAA to another PAA may be required for the
performance reason. The new section 4.9 (Mobility Handling) is added
describing this.Issue 15:It was mentioned that the cookie mechanism defined for the discovery and
handshake phase might not be effective for controlling the on-link
attackers. In Puzzle mechanism, PAA sends a challenge that does not need a
shared secret for a PaC to respond but need some calculation on PaC. The
current proposal is to make cookie as a default and study more on the
security aspects of puzzle and include it in some separate document.Issues 18,19:Some of the result codes ported from the DIAMETER are intended to be used
for the PANA-Result-Request message.Issue 1,3:The discussion took place whether PANA needs to support capability
negotiation. The capability negotiation outside of the EAP can be placed for
downgrading the attack. The proposed solution is to support
capability indication.Topic 5. Next steps
----------------------------------------
---------------------------------Basavaraj Patil talked about the next steps for the WG. PANA-IPsec draft
will be updated based on the feedback. The goal is to finish the PANA
protocol specification by next IETF. Provisioning protocol
discussions will continue on the PANA mailing list. We will arrange an
interoperability testing among the implementors of PANA.
|