1 / 9

PANA Specification Updates (draft-ietf-pana-pana-10.txt)

PANA Specification Updates (draft-ietf-pana-pana-10.txt). Yoshihiro Ohba (yohba@tari.toshiba.com). Issue 155: Re-authentication phase. Issue: Re-authentication phase is described as a separate phase from access phase

lbillie
Télécharger la présentation

PANA Specification Updates (draft-ietf-pana-pana-10.txt)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PANA Specification Updates(draft-ietf-pana-pana-10.txt) Yoshihiro Ohba (yohba@tari.toshiba.com) IETF63 PANA WG

  2. Issue 155: Re-authentication phase • Issue: Re-authentication phase is described as a separate phase from access phase • Giving an impression that network access is not allowed during re-authentication phase, which is not true • Solution: • Define re-authentication phase within access phase

  3. Issue 163: 2nd review by Jari Arkko • Issue: The following sentence in Abstract is too strong particularly if we describe some EAP method requirement in the spec • “PANA can carry any authentication method that can be specified as an EAP method, and it can be used on any link that can carry IP.” • Resolution: Removed the sentence

  4. Issue 163: 2nd review by Jari Arkko (cont’d) • Issue: It is not clear about S-flag handling during re-authentication • Resolution: S-flag value needs to be inherited from the previous authentication and authorization phase or re-authentication phase

  5. Issue 165: Nonce and stateless PAA discovery • Issue: Inclusion of Nonce AVP in PSR conflicts with stateless PAA discovery • PAA cannot be stateless since the nonce contains a random value • Resolution: • Nonce AVPs are not carried in PSR/PSA in case of stateless PAA discovery • Instead, they are carried in the first PAR/PAN exchange

  6. Issue 166: Retransmission bug • Issue: There is a leftover of old (and incorrect) retransmission rule in Section “Retransmission Timers” • Resolution: Removed the incorrect retransmission rule from the section

  7. Issue 169: Lower-layer ciphering • Issue: Need for an algorithm for deriving a key used for bootstrapping lower-layer ciphering for any lower-layers • Resolution: Defined PaC-EP-Master key PaC-EP-Master-Key = HMAC-SHA-1 (AAA-Key, "PaC-EP master key Session ID | Key-ID | EP-Device-Id) • EP-Device-Id: The Value field of Device-Id AVP of given EP • Since Device-Id contains address family, the key derivation algorithm is generic enough to guarantee cryptographic separation among different EPs even across different lower-layers

  8. Issue 170: Dual stack • Issue: Details are missing in dual stack support • Resolution: • Partitioned D-flag into two • F (DHCPv4) • S (DHCPv6) • The PAA MUST set either the N-flag, or one or more of the other flags • The PaC MUST echo the same flags in response • When IPsec ciphering is not used, F, S or A flag MUST be set by the PAA

  9. Issue: Notification AVP • Issue: Does ‘M’ bit of Notification AVP need to be set? • Notification AVP contains displayable message • No additional processing rule is defined (the receiver can ignore the contents of the Notification AVP) • Resolution: Added the following sentence • “The 'M' bit in the AVP header of this AVP MUST NOT be set.”

More Related