Minutes of: Protocol for carrying Authentication for Network Access (pana) At: IETF67 November 6, 2006 (San Diego, USA) Chairs: Basavaraj Patil Alper Yegin Credit for these minutes: 1. Victor Fajardo (vfajardo at tari dot toshiba dot com) 2. Also Wassim Haddad (wassim dot haddad at ericsson dot com) ############################################ 1. PANA Spec WG Document Status - AD review completed - SECDIR review completed - Ready for WG last call - Revisions required before WG last call 2. PANA Protocol Revision (Issues and Resolution) Speaker: Yoshihiro Ohba - AD review after IETF last call - PANA is getting more simplified Comments: Alper : Waiting for external review on language tag usage in Notification AVP Mark : Still waiting for input - will lookup - Issues discussion #1 Session-Id * Globally unique session id is not needed * Use 4-octed session-id field in the PANA header, remove session-id avp * Session-id is asssinged by PAA in the PSR/PSA exchange * Therefore, UNKNOWN_SESSION_ID error can be removed #2 Stateless handshake * Simplification of the stateless handshake - Removal of L-bit ? - Need to keep a minimum state to be maintained (cookie, initial seq) - Adding PSR retransmission to this state is not a big issue * Solution: - Remove distinction between stateless and stateful - Remove cookie avp - Remove L-flag - PSR re-transmission may be turned off if PAA wants to be stateless #3 Device-Id * Do we need Device-Id ? Is IP address enough ? * Solution: - Remove text for Device-Id determination in the spec, maybe define this scheme in other documents - Remove text from Section 2 of the spec - Remove Device-Id AVP #4 Bootstrapping Lower-layer * Bootstrapping functionality thould be removed * Solution: - Remove PCAP AVP #5 Post-PANA Address Configuration * PPAC should be removed from spec * List discussion: - IP address configuration is orthogonal and out of scope - Each address configuration has its own re-config notification * Solution: - Remove PPAC AVP - Remove appendix A #6 Network Selection * Can be better defined in separate ID - Use RADIUS operator ID in place of SMI vendor id (needs discussion) * Solution: - Remove network selection functionality - Remove related network selection AVPs #7 Nonce AVP * Sometimes contained ins PAR/PAN or PSR/PSA, simplify * Solution: - Remove Nonce from PSR/PSA - Specify that Nonce is carried only in the first PAR/PAN exchange #8 Filtering excpetion * Needs text for describing that EP needs to pass certain IP packets that are exchange prior to PANA operation (i.e. DHCP) * Solution: - Added new text breifly mentioning this requirement Comments: Alper : We need to discuss with AD to clarify the proposed text Mark : Filtering discussion began with Device-Id discussion. Why do you need it ? Because this is filtering (blocking certain traffic) If you don't have Device-Id how do you know which traffic to block. So either the spec needs to define one mode of operation when the Device-Id is one form OR it is say that filtering outside the scope of the doc. EP may be multiples-hop away and not in the path where it is capable of blocking traffic. Jari : Propse text where EP is several hops away. Details what this traffic type is. Its one way of avoiding this question Raj : If EP is a bridge, it makes sense to allow DHCP and other traffic to pass. Need to have clarification of where the EP is located. Jari : The current text is only for hand waving or warning. It will not be easy to get all scenarios documented. Raj : Why not use IP level filtering Mark : I'm happy with document as it is including IP filtering mode. But it has to be clear where the EP should be. Its un-realistic to define how it works in every case. Alper : Even if the spec wants to concern itself with other cases, it is up to the EP to implement enforcement. Jari : But readers of the spec needs to understand how this works. EP enforcement is outside of the protocol but still part of the system Alper : How about putting the text in the framework document Mark : Framework document is informational. Suggest we pick one mode or scenario that can be described OR declare the topic as out of scope Alper : I prefer the second option Glen : Its not impossible to specify the scenario regardless of the location of the EP but it is impossible to specify the traffic that passing through it. Raj : The current text does not mean anything from implementation point of view. Jari : Yes. One approach is to say that specific applicaitons of pana has to specify how that scenario happens, i.e. PANA-IPsec document Raj : Do we make this out of scope ? Or spec should say something Jari : At least one doc should say something. If its not in the spec then it becomes completely open to different interpretation. Subir : I agree with glen. If EP is 15 hops way, it will not be able to filter. Depending on the architecture then just say which traffic will be blocked. Alper : It does not matter whether it is authorized or not, that kind of traffic will have to go through the EP. Mark : With this text how do you know which is authorized client ? I'm happy if the spec says at least one model, say IP. It makes more sense because we have something implementors can act on. Subir : We need to say what kind of message your blocking Jari : But its not enough. Subir : How do you know which traffic from the client your passing ? Jari : This depends on where the EP is. I would really like to see implementable text that needs to be blocked, i.e. protocol number, types, icmp ranges etc. Alper : I agree but the discussion goes back to the spec. It's best not to discuss this at all. Jari : Leave text but needs to be specified in other architecture Alper : How much details do we need in the spec ? Jari : Only application should specify these cases Alper : Definition of un-authorized client and the allowed traffic type can be found in other spec, just add ref to the those spec #9 EAP message duplication handling * Do we still need to specify eap message duplication ? * Soultion: It should be removed #10 IP source/dest address #11 UDP port number * Why not always use well-know port number for destination port ? * Discussion - Use of an ephemeral port number contained in a request - Makes firewall traversal for PANA more difficult * Soultion: - Response is same rule #12 AVP message allocation policy * Missing spec on how to allocate mandatory supported avp or new message - IANA namepsce would be needed * Discussion - Mandatory-to-support AVP or new message would require new a new version of PANA specification * Solution: - Add "Standard actions" #13 PANA-error-requiest * PER needs to contain info on on what caused an error * Add new new Failed-Message-Header AVP #14 Condition to terminate request re-transmission * Request re-transmission is terminated when protected PER for the request is recieved #15 Other changes * Result-code AVP changes * Protocol error result changes * Include number of experimental message type from 2 to 16 Comments: Alper : Once we converge these soultions and send it back to Mark Mark : Make a short IETF last call after compilation of these changes 3. DHCP options for PAA (Lionel) Speaker: Lionel - Report on DHCP options for PAA - Defintion of new DHCP option to local PAA in access network - Status - WG last call on *-03 issued in IETF66 - Prallel work in DHC WG and PANA WG - Work Completely done Sept 1, 2006 - Output: - Draft passed WGLC on both DHC and PANA WG - AD Review: - Jari, Thomas, Bernard - Results provided on 10/10 #1 Resolution of DHCP option in the PANA framework - Used only to discover PAA address ? - Dynamic mechanism to inform DHCP client that PANA MUST be used Comments: Jari : Some warning on security issues is needed when trying to use this method #2 Behavior of the DHCP nodes and Pac - Add text to clarify that * PAC should request DHCP PAA Option * DHCP server should send a client with the PAA option #3 Security considerations - If PANA is used for turning pana on/off * implications for spoofed PAA address ? * Risk of bidding down attacks - Answer: related to issue #1 - There is no specific security issue if it clearly states that the option is used only to discover the PAA - Add some text in the scurity seciton to explain the issues Comments: Jari : I'm happy with all of these once all these text will appear Alper : Where not using this text as a mechanisms Jari : This is just a warning when discovered PAA address is found Alper : It is equivalient to unprotected discovery mechanism Jari : Similar issues with other scheme and this is enough Next steps: - Provide revisions based on discussion - Move the draft forward to IETF last call 4. PANA in DSL networks - New draft which describes use of PANA in DSL networks - Once the PANA framework document was simplified, the PANA use cases for DSL an WLAN was removed - Done in version 07 - This draft is a spin off from the framework draft - Focus on DSL networks migration from traditional PPP access model to pure IP base access environment Use case - Evolution of DSL architecture - Two steps ATM to Gig and PPP to IP based - IP session model introduced in DSL forum - Currently, there is no built-in authentcaion mechanism Why use PANA ? - Security requiremetns required in DSL forum Location of PAA and EP - PPP base where BRAS is in charge of CPE network access - In IP-Session based enviroment - Functionality may be provided by the PAA and EP in the BRAS - It is possible to have PAA and BRAS to be not collocated Localion of Pac - CPE can be an L2 bridge and the Pac should be implemented in the host - CPE can be an IPv6 router then PAC should be in the CPE and host Comments: Yoshi : In IPv6 case, is the IP address is a global address ? Lionel : IP address should be visible from the BRAS, can be global or local depending on topology Other contents - Consideration for IP address configuration Comments: Yoshi : For post PANA address notification are you relying on the IPv4 DHCP notificaiton scheme. What about IPv6 ? Lionel : For PPAC notification, rely on what is existing Voytek : IP is discarded in IPv4 after Auth. How do you propose protecting this scarce resource in the pre-PANA address ? Lionel : We can rely on private IP address post PANA address Voytek : Even using private IP can still exhaust the address space Alper : If we rely on private IP, IP address exhaustion attack should be dtectable and since it is a brute force Mark : Security considration should say this Voytek : Always use a DHCP server ? Or are there other methods specially for embedded devices ? Mark : Are these address configuration assumptions need to be documented ? Alper : Who's assuming that DHCP server is external ? Lionel : From the DSL forum, it should be external Alper : Is the DHCP server on the BRAS Mark : Is there an attack here where we can deplete the IP addresses ? The class of DHCP server existing on the BRAS is not as feature filled. Next steps: - Collect inputs from the group - What level of detail sufficient ? - Should the draft be a WG document ? 5. PANA API draft Comments: Raj : Should this be a working group draft ? API documents are not necessarily WG docs Mark : Its not within the working group theme Raj : Other groups have published APIs such as MIPv6 Recommend that the work be progressed. Chairs to find the opinion of the WG via the ML.