| draft-ietf-pana-pana-03c.txt | draft-ietf-pana-pana-03.txt | |
|---|---|---|
| PANA Working Group D. Forsberg | PANA Working Group D. Forsberg | |
| Internet-Draft Nokia | Internet-Draft Nokia | |
| Expires: August 6, 2004 Y. Ohba | Expires: August 9, 2004 Y. Ohba | |
| Toshiba | Toshiba | |
| B. Patil | B. Patil | |
| Nokia | Nokia | |
| H. Tschofenig | H. Tschofenig | |
| Siemens | Siemens | |
| A. Yegin | A. Yegin | |
| DoCoMo USA Labs | DoCoMo USA Labs | |
| February 6, 2004 | February 9, 2004 | |
| Protocol for Carrying Authentication for Network Access (PANA) | Protocol for Carrying Authentication for Network Access (PANA) | |
| draft-ietf-pana-pana-03c | draft-ietf-pana-pana-03 | |
| Status of this Memo | Status of this Memo | |
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |
| all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |
| Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |
| groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |
| Skipping to change at page 1, line 38: | ||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |
| The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |
| www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |
| This Internet-Draft will expire on August 6, 2004. | This Internet-Draft will expire on August 9, 2004. | |
| Copyright Notice | Copyright Notice | |
| Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). All Rights Reserved. | |
| Abstract | Abstract | |
| This document defines the Protocol for Carrying Authentication for | This document defines the Protocol for Carrying Authentication for | |
| Network Access (PANA), a link-layer agnostic transport for Extensible | Network Access (PANA), a link-layer agnostic transport for Extensible | |
| Authentication Protocol (EAP) to enable network access authentication | Authentication Protocol (EAP) to enable network access authentication | |
| Skipping to change at page 6, line 25: | ||
| (i.e., filters) are applied on the inbound and outbound traffic of | (i.e., filters) are applied on the inbound and outbound traffic of | |
| client devices. Information such as DI and (optionally) | client devices. Information such as DI and (optionally) | |
| cryptographic keys are provided by PAA per client for constructing | cryptographic keys are provided by PAA per client for constructing | |
| filters on the EP. | filters on the EP. | |
| Network Access Provider (NAP): | Network Access Provider (NAP): | |
| A service provider that provides physical and link-layer | A service provider that provides physical and link-layer | |
| connectivity to an access network it manages. | connectivity to an access network it manages. | |
| Master Session Key (MSK): | AAA-Key: | |
| Keying material (at least 64 octets) that is derived between the | ||
| EAP client and server and exported by the EAP method. | ||
| The definition of the terms PANA Client (PaC), PANA Authentication | A key derived by the EAP peer and EAP server and transported to | |
| Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be | the authenticator [I-D.ietf-eap-keying]. | |
| found in [I-D.ietf-pana-requirements]. | ||
| 3. Protocol Overview | 3. Protocol Overview | |
| The PANA protocol involves two functional entities namely the PaC and | The PANA protocol involves two functional entities namely the PaC and | |
| the PAA. The protocol resides above the transport layer and the | the PAA. The protocol resides above the transport layer and the | |
| details are explained in Section 4. | details are explained in Section 4. | |
| The placement of the entities used in PANA largely depends on a | The placement of the entities used in PANA largely depends on a | |
| certain architecture. The PAA may optionally interact with a AAA | certain architecture. The PAA may optionally interact with a AAA | |
| backend to authenticate the user (PaC). The EP, mentioned in the | backend to authenticate the user (PaC). The EP, mentioned in the | |
| Skipping to change at page 9, line 49: | ||
| o Session-Id AVP: contains the session identifier value. | o Session-Id AVP: contains the session identifier value. | |
| o Session-Lifetime AVP: contains the duration of authorized access. | o Session-Lifetime AVP: contains the duration of authorized access. | |
| o Failed-AVP: contains the offending AVP that caused a failure. | o Failed-AVP: contains the offending AVP that caused a failure. | |
| o NAP-Information AVP, ISP-Information AVP: contains the information | o NAP-Information AVP, ISP-Information AVP: contains the information | |
| on a NAP and an ISP, respectively. | on a NAP and an ISP, respectively. | |
| o Key-Id AVP: contains an MSK identifier. | o Key-Id AVP: contains a AAA-Key identifier. | |
| 4.1.2 Transport Layer Protocol | 4.1.2 Transport Layer Protocol | |
| PANA uses UDP as its transport layer protocol. The UDP port number | PANA uses UDP as its transport layer protocol. The UDP port number | |
| is TBD. All messages except for PANA-PAA-Discover are always | is TBD. All messages except for PANA-PAA-Discover are always | |
| unicast. PaC MUST NOT use unspecified IP address for communicating | unicast. PaC MUST NOT use unspecified IP address for communicating | |
| with PAA. | with PAA. | |
| 4.1.3 Fragmentation | 4.1.3 Fragmentation | |
| Skipping to change at page 11, line 13: | ||
| retransmission timer is stopped) or the number of retransmission | retransmission timer is stopped) or the number of retransmission | |
| reaches the maximum value (in which case the PANA session MUST be | reaches the maximum value (in which case the PANA session MUST be | |
| deleted immediately). For PANA-layer retransmission, the | deleted immediately). For PANA-layer retransmission, the | |
| retransmission timer SHOULD be calculated as described in [RFC2988] | retransmission timer SHOULD be calculated as described in [RFC2988] | |
| to provide congestion control. See Section 10 for default timer and | to provide congestion control. See Section 10 for default timer and | |
| maximum retransmission count parameters. | maximum retransmission count parameters. | |
| 4.1.5 PANA Security Association | 4.1.5 PANA Security Association | |
| A PANA SA is created as an attribute of a PANA session when EAP | A PANA SA is created as an attribute of a PANA session when EAP | |
| authentication succeeds with a creation of a Master Session Key (MSK) | authentication succeeds with a creation of a AAA-Key. A PANA SA is | |
| [I-D.ietf-eap-rfc2284bis]. A PANA SA is not created when the PANA | not created when the PANA authentication fails or no AAA-Key is | |
| authentication fails or no MSK is produced by any EAP authentication | produced by any EAP authentication method. In the case where two EAP | |
| method. In the case where two EAP authentications are performed in a | authentications are performed in a sequence in a single PANA | |
| sequence in a single PANA authentication, it is possible that two | authentication, it is possible that two AAA-Keys are derived. If this | |
| MSKs are derived. If this happens, the PANA SA MUST be bound to the | happens, the PANA SA MUST be bound to the AAA-Key derived from the | |
| MSK derived from the first EAP authentication. When a new MSK is | first EAP authentication. When a new AAA-Key is derived as a result | |
| derived as a result of EAP-based re-authentication, any key derived | of EAP-based re-authentication, any key derived from the old AAA-Key | |
| from the old MSK MUST be updated to a new one that is derived from | MUST be updated to a new one that is derived from the new AAA-Key. | |
| the new MSK. In order to distinguish the new MSK from old ones, one | In order to distinguish the new AAA-Key from old ones, one Key-Id AVP | |
| Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer | MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at | |
| message at the end of the authentication phase which resulted in | the end of the authentication phase which resulted in deriving a new | |
| deriving a new MSK. The Key-Id AVP is of type Unsigned32 and MUST | AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a | |
| contain a value that uniquely identifies the MSK within the PANA | value that uniquely identifies the AAA-Key within the PANA session. | |
| session. The PANA-Bind-Answer message sent in response to a | The PANA-Bind-Answer message sent in response to a PANA-Bind-Request | |
| PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with | with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key | |
| the same MSK identifier carried in the request. PANA-Bind-Request | identifier carried in the request. PANA-Bind-Request and | |
| and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC | PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP | |
| AVP whose value is computed by using the new MSK. Although the | whose value is computed by using the new AAA-Key. Although the | |
| specification does not mandate a particular method for calculation of | specification does not mandate a particular method for calculation of | |
| Key-Id AVP value, a simple method is to use monotonically increasing | Key-Id AVP value, a simple method is to use monotonically increasing | |
| numbers. | numbers. | |
| The created PANA SA is deleted when the corresponding PANA session is | The created PANA SA is deleted when the corresponding PANA session is | |
| deleted. The lifetime of the PANA SA is the same as the lifetime of | deleted. The lifetime of the PANA SA is the same as the lifetime of | |
| the PANA session for simplicity. | the PANA session for simplicity. | |
| PANA SA attributes as well as PANA session attributes are listed | PANA SA attributes as well as PANA session attributes are listed | |
| below: | below: | |
| Skipping to change at page 12, line 22: | ||
| * Last transmitted message payload | * Last transmitted message payload | |
| * Retransmission interval | * Retransmission interval | |
| * Session lifetime | * Session lifetime | |
| * Protection-Capability | * Protection-Capability | |
| * PANA SA attributes: | * PANA SA attributes: | |
| + MSK | + AAA-Key | |
| + MSK Identifier | + AAA-Key Identifier | |
| + PANA_MAC_Key | + PANA_MAC_Key | |
| The PANA_MAC_Key is used to integrity protect PANA messages and | The PANA_MAC_Key is used to integrity protect PANA messages and | |
| derived from the MSK in the following way: | derived from the AAA-Key in the following way: | |
| PANA_MAC_KEY = The first N bits of | PANA_MAC_KEY = The first N bits of | |
| HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID) | HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) | |
| where the value of N depends on the integrity protection algorithm in | where the value of N depends on the integrity protection algorithm in | |
| use, i.e., N=160 for HMAC-SHA1. | use, i.e., N=160 for HMAC-SHA1. | |
| The length of MSK MUST be N bits or longer. See Section 4.1.6 for | The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 | |
| the detailed usage of the PANA_MAC_Key. | for the detailed usage of the PANA_MAC_Key. | |
| 4.1.6 Message Authentication Code | 4.1.6 Message Authentication Code | |
| A PANA message can contain a MAC (Message Authentication Code) AVP | A PANA message can contain a MAC (Message Authentication Code) AVP | |
| for cryptographically protecting the message. | for cryptographically protecting the message. | |
| When a MAC AVP is included in a PANA message, the value field of the | When a MAC AVP is included in a PANA message, the value field of the | |
| MAC AVP is calculated by using the PANA_MAC_Key in the following way: | MAC AVP is calculated by using the PANA_MAC_Key in the following way: | |
| MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) | MAC AVP value = PANA_MAC_PRF(PANA_MAC_Key, PANA_PDU) | |
| Skipping to change at page 24, line 11: | ||
| authentication and create a fresh PANA session from scratch. | authentication and create a fresh PANA session from scratch. | |
| In case the new PAA retrieves the on-going PANA session attributes | In case the new PAA retrieves the on-going PANA session attributes | |
| from the previous PAA, the PANA session continues with a PANA-Reauth | from the previous PAA, the PANA session continues with a PANA-Reauth | |
| exchange. The MAC AVP contained in the PANA-Reauth messages MUST be | exchange. The MAC AVP contained in the PANA-Reauth messages MUST be | |
| generated and verified by using the retrieved PANA SA attributes. | generated and verified by using the retrieved PANA SA attributes. | |
| This exchange MUST also include Session-Id AVP that contains the | This exchange MUST also include Session-Id AVP that contains the | |
| newly assigned session identifier, and Device-Id AVP. A new PANA | newly assigned session identifier, and Device-Id AVP. A new PANA | |
| session is created upon successful completion of this exchange. This | session is created upon successful completion of this exchange. This | |
| session inherits only the session lifetime, protection capability, | session inherits only the session lifetime, protection capability, | |
| and MSK attributes from the previous session. Other attributes are | and AAA-Key attributes from the previous session. Other attributes | |
| generated based on the PANA exchanges on the new link. While MSK | are generated based on the PANA exchanges on the new link. While | |
| stays the same, a new PANA_MAC_Key is computed using the new | AAA-Key stays the same, a new PANA_MAC_Key is computed using the new | |
| parameters. Subsequent MAC-AVPs are processed using this new PANA SA. | parameters. Subsequent MAC-AVPs are processed using this new PANA SA. | |
| 4.10 Event Notification | 4.10 Event Notification | |
| Upon detecting the need to authenticate a client, EP can send a | Upon detecting the need to authenticate a client, EP can send a | |
| trigger message to the PAA on behalf of the PaC. This can be one of | trigger message to the PAA on behalf of the PaC. This can be one of | |
| the messages provided by the PAA-to-EP protocol, or, in the absence | the messages provided by the PAA-to-EP protocol, or, in the absence | |
| of such a facility, PANA-PAA_Discover can be used as well. This | of such a facility, PANA-PAA_Discover can be used as well. This | |
| message MUST carry the device identifier of the PaC. So that, the PAA | message MUST carry the device identifier of the PaC. So that, the PAA | |
| can send the unsolicited PANA-Start-Request message directly to the | can send the unsolicited PANA-Start-Request message directly to the | |
| Skipping to change at page 30, line 11: | ||
| If set, the message is a request. If cleared, the message is an | If set, the message is a request. If cleared, the message is an | |
| answer. | answer. | |
| S(eparate) | S(eparate) | |
| When the S-flag is set in a PANA-Start-Request message it | When the S-flag is set in a PANA-Start-Request message it | |
| indicates that PAA is willing to offer separate EAP | indicates that PAA is willing to offer separate EAP | |
| authentication for NAP and ISP. When the S-flag is set in a | authentication for NAP and ISP. When the S-flag is set in a | |
| PANA-Start-Answer message it indicates that PaC accepts on | PANA-Start-Answer message it indicates that PaC accepts on | |
| performing separate EAP authentication for NAP and ISP." | performing separate EAP authentication for NAP and ISP. | |
| r(eserved) | r(eserved) | |
| these flag bits are reserved for future use, and MUST be set to | these flag bits are reserved for future use, and MUST be set to | |
| zero, and ignored by the receiver. | zero, and ignored by the receiver. | |
| Message Type | Message Type | |
| The Message Type field is three octets, and is used in order to | The Message Type field is three octets, and is used in order to | |
| communicate the message type with the message. The 24-bit address | communicate the message type with the message. The 24-bit address | |
| Skipping to change at page 34, line 27: | ||
| PANA-Auth-Request ::= < PANA-Header: 3, REQ > | PANA-Auth-Request ::= < PANA-Header: 3, REQ > | |
| < Session-Id > | < Session-Id > | |
| < EAP-Payload > | < EAP-Payload > | |
| 0*1 [ NAP-Information ] | 0*1 [ NAP-Information ] | |
| 0*1 [ ISP-Information ] | 0*1 [ ISP-Information ] | |
| * [ AVP ] | * [ AVP ] | |
| 0*1 < MAC > | 0*1 < MAC > | |
| (Both NAP-Information and ISP-Information MUST NOT be included at the | (Both NAP-Information and ISP-Information MUST NOT be included at the | |
| same time)" | same time) | |
| 9.3.6 PANA-Auth-Answer (PAN) | 9.3.6 PANA-Auth-Answer (PAN) | |
| PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a | PANA-Auth-Answer (PAN) is sent by the PaC to the PAA in response to a | |
| PANA-Auth-Request message. | PANA-Auth-Request message. | |
| PANA-Auth-Answer ::= < PANA-Header: 3 > | PANA-Auth-Answer ::= < PANA-Header: 3 > | |
| < Session-Id > | < Session-Id > | |
| < EAP-Payload > | < EAP-Payload > | |
| * [ AVP ] | * [ AVP ] | |
| Skipping to change at page 43, line 16: | ||
| 9.4.14 Provider-Name AVP | 9.4.14 Provider-Name AVP | |
| The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and | The Provider-Name AVP (AVP Code: 1037) is of type UTF8String, and | |
| contains the UTF8-encoded name of the provider. | contains the UTF8-encoded name of the provider. | |
| 9.4.15 EP-Device-Id AVP | 9.4.15 EP-Device-Id AVP | |
| The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier | The EP-Device-Id AVP (AVP Code: 1038) contains the device identifier | |
| of an EP. The payload format of the EP-Device-Id AVP is the same as | of an EP. The payload format of the EP-Device-Id AVP is the same as | |
| that of the Device-Id AVP (see See section Section 9.4.2)." | that of the Device-Id AVP (see See section Section 9.4.2). | |
| 9.4.16 Key-Id AVP | 9.4.16 Key-Id AVP | |
| The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an | The Key-Id AVP (AVP Code: 1039) is of type Integer32, and contains an | |
| MSK identifier. The MSK identifier is assigned by PAA and MUST be | AAA-Key identifier. The AAA-Key identifier is assigned by PAA and | |
| unique within the PANA session. | MUST be unique within the PANA session. | |
| 9.5 AVP Occurrence Table | 9.5 AVP Occurrence Table | |
| The following tables lists the AVPs used in this document, and | The following tables lists the AVPs used in this document, and | |
| specifies in which PANA messages they MAY, or MAY NOT be present. | specifies in which PANA messages they MAY, or MAY NOT be present. | |
| The table uses the following symbols: | The table uses the following symbols: | |
| 0 The AVP MUST NOT be present in the message. | 0 The AVP MUST NOT be present in the message. | |
| Skipping to change at page 49, line 62: | ||
| physical or link layer security is available. The PANA SA allows | physical or link layer security is available. The PANA SA allows | |
| subsequently exchanged messages to experience cryptographic | subsequently exchanged messages to experience cryptographic | |
| protection. For the current version of the document an integrity | protection. For the current version of the document an integrity | |
| object (MAC AVP) is defined which supports data-origin | object (MAC AVP) is defined which supports data-origin | |
| authentication, replay protection based on sequence numbers and | authentication, replay protection based on sequence numbers and | |
| integrity protection based on a keyed message digest. Confidentiality | integrity protection based on a keyed message digest. Confidentiality | |
| protection is not provided. The session keys used for this object | protection is not provided. The session keys used for this object | |
| have to be provided by the EAP method. For this version of the | have to be provided by the EAP method. For this version of the | |
| document it is assumed that no negotiation of algorithms and | document it is assumed that no negotiation of algorithms and | |
| parameters takes place. Instead HMAC-SHA1 is used by default. A | parameters takes place. Instead HMAC-SHA1 is used by default. A | |
| different algorithm such as HMAC-MD5 might be used as an option. The | different algorithm may be chosen by default in a future version of | |
| used algorithm is indicated in the header of the Integrity object. To | the PANA protocol specification. The used algorithm is indicated in | |
| select the security association for signaling message protection the | the header of the Integrity object. To select the security | |
| Session ID is conveyed. The keyed message digest included in the | association for signaling message protection the Session ID is | |
| Integrity object will include all fields of the PANA signaling | conveyed. The keyed message digest included in the Integrity object | |
| message including the sequence number field of the packet. | will include all fields of the PANA signaling message including the | |
| sequence number field of the packet. | ||
| The protection of subsequent signaling messages prevents an adversary | The protection of subsequent signaling messages prevents an adversary | |
| from acting as a man-in-the-middle adversary, from injecting packets, | from acting as a man-in-the-middle adversary, from injecting packets, | |
| from replaying messages and from modifying the content of the | from replaying messages and from modifying the content of the | |
| exchanged packets. This prevents subsequently described threats. | exchanged packets. This prevents subsequently described threats. | |
| If an entity (PAA or PaC) loses its state (especially the current | If an entity (PAA or PaC) loses its state (especially the current | |
| sequence number) then the entire PANA protocol has to be restarted. | sequence number) then the entire PANA protocol has to be restarted. | |
| No re-synchronization procedure is provided. | No re-synchronization procedure is provided. | |
| Skipping to change at page 49, line 209: | ||
| The remaining issues for -xx version of draft are: 28, 52, 53, 54, | The remaining issues for -xx version of draft are: 28, 52, 53, 54, | |
| 55, 56, 57, 58 and 59. | 55, 56, 57, 58 and 59. | |
| 13. Change History | 13. Change History | |
| Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. | Issues incorporated in PANA-01 June 2003: 1, 3, 10, 5, 6, 7 and 11. | |
| Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, | Issues incorporated in PANA-02 October 2003: 8, 17, 18, 19, 20, 21, | |
| 22, 23, 24, 25, 26, 30, 31, 32 and 33. | 22, 23, 24, 25, 26, 30, 31, 32 and 33. | |
| Issues incorporated in PANA-03c: 2, 16, 34, 35, 36, 38, 39, 40, 42, | Issues incorporated in PANA-03 February 2004: 2, 16, 34, 35, 36, 38, | |
| 43, 44, 50 and 51. | 39, 40, 42, 43, 44, 50, 51 and 60. | |
| 14. Acknowledgments | 14. Acknowledgments | |
| We would like to thank all members of the PANA working group for | We would like to thank all members of the PANA working group for | |
| their comments to this document. | their comments to this document. | |
| Normative References | Normative References | |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. |