12/05/2007IETF70 PANA WG1 PANA Network Selection draft-ohba-pana-netsel-00.txt Yoshihiro Ohba

12/05/2007IETF70 PANA WG2 Background Network selection was defined older revisions of PANA specification to provide following functions –NAP and ISP separate authentication –ISP selection During IETF last call, network selection was removed from PANA specification, with suggestion to define it in a separate document This draft is submitted as such a document

12/05/2007IETF70 PANA WG3 A new bit in PANA Header for NETSEL |R S C A P I N r r r r r r r r r| N(Network Selection) This bit is set when the sender supports network selection function

12/05/2007IETF70 PANA WG4 ‘N’ bit Usage The PAA and PaC advertise their support for the network selection function in the initial PAR and PAN messages with both 'S’ (Start) and ‘N’ (Network selection) bits set. If 'N' bit is set in both messages, the PAA and PaC may start NAP and ISP Separate Authentication and/or ISP selection

12/05/2007IETF70 PANA WG5 NAP and ISP Separate Authentication Two PANA sessions are established between the PaC and PAA, one for NAP authentication and the other for ISP authentication. For the PANA session used for NAP authentication, PAR message sent in response to the initial PAR-PAN exchange with 'S' (Start) bit set carries one NAP-Information AVP. The PANA session used for ISP authentication MUST NOT carry a NAP-Information AVP. When a PANA SA is established, the same NAP-Information AVP MUST be carried in the last PANA-Auth-Request message with 'C' (Complete) bit set with an AUTH AVP –Issue: PANA SA should be a MUST considering crypto binding (see below) When NAP and ISP separate authentication is performed, cryptographic binding MUST be made between the two session –How the cryptographic binding is created is TBD

12/05/2007IETF70 PANA WG6 ISP Selection ISP selection MUST NOT be performed over a session used for NAP authentication. ISP selection MAY be performed in the absence of NAP and ISP separate authentication The second PAR message (with ‘S’ bit cleared) with ‘N’ bit set carries one or more ISP-Information AVPs –When there is only one ISP-Information AVP, there is only one ISP choice The PAN message sent in response to this PAR message carries at most one ISP-Information AVP to indicate the ISP chosen by the PaC. –In the absence of an ISP in the PAN, ISP selection is typically performed based on the client identifier (e.g., using the realm portion of an NAI carried in EAP method). When a PANA SA is established, the ISP-Information AVP for the selected ISP MUST be carried in the last PAR message with 'C' (Complete) bit set with an AUTH AVP

12/05/2007IETF70 PANA WG7 Example Call Flow (NAP Authentication) PaC PAA PCI PSR[S=N=1]{Algorithm} PSA[S=N=1]{Algorithm} PAR[C=N=1]{NAP-Information, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} : PSA[N=1]{EAP-Payload} PSR[N=1]{NAP-Information, EAP-Payload} PSA[N=1]{EAP-Payload} PSR[N=1]{EAP-Payload}

12/05/2007IETF70 PANA WG8 Example Call Flow (ISP Selection w/ one ISP choice) PaC PAA PCI PSR[S=N=1]{Algorithm} PSA[S=N=1]{Algorithm} PAR[C=N=1]{ISP-Information, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} : PSA[N=1]{EAP-Payload} PSR[N=1]{ISP-Information, EAP-Payload} PSA[N=1]{EAP-Payload} PSR[N=1]{EAP-Payload}

12/05/2007IETF70 PANA WG9 Example Call Flow (ISP Selection w/ two ISP choices) PaC PAA PCI PSR[S=N=1,SID=y]{Algorithm} PSA[S=N=1,SID=y]{Algorithm} PAR[C=N=1]{ISP-Information, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} : PSA[N=1]{ISP-Information,EAP-Payload} PSR[N=1]{ISP-Information, ISP-Information, EAP-Payload} PSA[N=1]{EAP-Payload} PSR[N=1]{EAP-Payload}

12/05/2007IETF70 PANA WG10 NAP-Information AVP ISP-Information AVP {NAP,ISP}-Information AVP is of type Octet- String that carries an {NAP,ISP} name encoded as a RADIUS Operator-Name attribute value [I- D.ietf-geopriv-radius-lo] (see below) | Namespace ID | Operator-Name | Operator-Name Namespace ID = ‘0’ (TADIG in GSM), ‘1’ (REALM), ‘2’ (E212), ‘3’ (ICC)

12/05/2007IETF70 PANA WG11 Thank You!