Subject: IETF 57 PANA meeting minutes

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Jul 2003 11:26:56 -0700

Hello,

IETF 57 PANA meeting minutes are below. Please let us know if there is any
need for corrections or additions. We'd like to thank Jayshree Bharatia and
Paulo Pagliusi for taking these notes during the meeting.

- Chairs

Protocol for Carrying Authentication for Network Access (PANA)
WG Meeting Minutes
=======================================================================
Session: Monday, July 14 at 1300-1500
Chairs:  Basavaraj Patil <[email-masked]>
         Alper Yegin <[email-masked]>

Note Takers: Jayshree Bharatia, Paulo Pagliusi

Topic 1. Drafts Status

Short discussion on the current document status was given by the Alper
Yegin.
-  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/ietf/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 draft
Proposed 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.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 31 Jul 2003 17:54:50 -0700

> 
> 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.
I am a bit confused by the above.  There was a very recent
discussion on icmp type selectors in the ipsec WG to be included in the
revised version of RFC2401. I don't remember the consensus except
that everyone voted for it. It might as well be there. Mobile IPv6
also needs it for fine grained selectors. So, I am not sure how
big this issue is. We can potentially say that "these selectors
are not needed once Ipsec provides the feature..". What else is
needed ?

What is the selector problem got to do with "more complicated" above ?
What is more complicated ? Could you explain ?

-mohan

> 
> 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.
> 
> 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. 
> 
> 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 
> 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.
> 
> 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 
> 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.
> 
> 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