Subject: [Pana] issue25 revised text [second shot]

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Oct 2003 16:59:02 -0700

I revised the text further as follows:

- F-flag was removed.  (Since we have introduced S-flag, F-flag would
not be needed any more.)
  
- Allow PAA to include NSP-Information AVP in PANA-Auth-Request for
NAP authentication to unambiguously distinguish NAP authentication and
ISP authentication in the authentication phase, even when PaC did not
specify ISP-Information AVP during discovery and initial handshake
phase.

- Provider-Identifier AVP becomes optional in NAP-Information AVP so
that small NAPs do not need to obtain IANA-assigned
Provider-Identifier.

----
In Section 4.2, change

From:

"  When a PaC receives the PANA-Start-Request message in response to
   the PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message. The PANA-Start-Answer message contains the initial sequence
   numbers in the tseq and rseq fields of the PANA header, a copy of
   the received Cookie as the PANA payload."

To:

"  PAA MAY enable NAP-ISP authentication separation by setting the
   S-flag of the message header of the PANA-Start-Request.  Also, the
   PANA-Start-Request MAY contain zero or one NAP-Information AVP and
   zero or more ISP-Information AVPs to advertise the information on
   the NAP and/or ISPs.

   When a PaC receives the PANA-Start-Request message in response to
   the PANA-PAA-Discover message, it responds with a PANA-Start-Answer
   message if it wishes to enter the authentication phase.  The
   PANA-Start-Answer message contains the initial sequence numbers in
   the tseq and rseq fields of the PANA header, a copy of the received
   Cookie (if any) as the PANA payload.

   If the S-flag of the received PANA-Start-Request message is not
   set, PaC MUST NOT set the S-flag in the PANA-Start-Answer message
   sent back to the PAA.  In this case, PaC can indicate its choice of
   ISP by including its ISP-Information AVP in the PANA-Start-Answer
   message. AAA routing will be based on the ISP choice if an
   ISP-Information AVP is specified in the PANA-Start-Answer message,
   otherwise it will be based on EAP identifier.

   If the S-flag of the received PANA-Start-Request message is set,
   PaC can indicate its desire to perform separate EAP authentication
   for NAP and ISP by setting the S-flag in the PANA-Start-Answer
   message. In this case, PaC can also indicate its choice of ISP by
   including its ISP-Information AVP in the PANA-Start-Answer message.
   AAA routing for NAP authentication will be based on the NAP.  AAA
   routing for ISP authentication will be based on the ISP choice if
   an ISP-Information AVP is specified in the PANA-Start-Answer
   message, otherwise it will be based on EAP identifier."

In Section 4.3 change

from:

"  A single PANA session can enable more than one EAP authentication.
   This is used to satisfy the separate NAP and ISP authentications
   scenario.  Each EAP authentication is delineated from the subsequent
   one.  The F-flag in the PANA header indicates if this was the final
   authentication from sender's perspective.  If the PAA enables two
   separate authentication, it should not set the F-flag in after the
   first EAP method.  This indicates PAA's willingness to offer another
   authentication method for NAP-ISP separation.  PaC can respond with
   the F-flag unset, indicating PaC's willingness to go through a
   second authentication method.  The PaC can optionally decline by
   setting the F-flag, and this concludes the PANA authentication.  If
   the PAA does not offer two levels of authentication, then it sets
   the F-flag even at the end of first EAP exchange.  In that case the
   PaC has no other option but to set the F-flag to mark the end of
   PANA authentication."

to:

"  When PaC and PAA negotiated during the discovery and initial
   handshake phase to perform separate NAP and ISP authentications in
   a single PANA session, the PAA determines the execution order of NAP
   authentication and ISP authentication.  In this case, the PAA can
   indicate which EAP authentication is currently occurring by
   including a NAP-Information or an ISP-Information AVP of the
   corresponding EAP authentication in PANA-Auth-Request message. In
   the case where the PaC agreed to perform separate authentications
   but did not specify its ISP choice in PANA-Start-Answer message,
   the PAA MUST include its NAP-Information AVP in PANA-Auth-Request
   message when it performs NAP authentication so that the PaC can
   always distinguish ISP authentication from NAP authentication.  The
   PAA MAY stop including a NAP-Information or an ISP-Information AVP
   once it receives the first PANA-Auth-Answer message of the current
   EAP authentication."

In Figures 4 and 8, 

remove "// F-flag set".

In Section 9.1 change

from:

"  Flags
                                                                                
     The Flags field is eight bits.  The following bits are assigned:
                                                                                
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |R r r r F r r r|
    +-+-+-+-+-+-+-+-+"
                                                                                
To:
                                                                                
"  Flags
                                                                                
     The Flags field is eight bits.  The following bits are assigned:
                                                                                
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |R r r r S r r r|
    +-+-+-+-+-+-+-+-+"

In Section 9.1 

delete:

"      F(inish)
                   - F-flag in the PANA header indicates if this  was
                     the final authentication from sender's
                     perspective.  If PAA enables two separate
                     authentication, it should not set F-flag in the
                     PANA-Bind-Request message after the first EAP
                     method."

add:

"      S(eparate)
                   - When the S-flag is set in a PANA-Start-Request
                     message it indicates that PAA is willing to offer
                     separate EAP authentication for NAP and ISP.
                     When the S-flag is set in a PANA-Start-Answer
                     message it indicates that PaC accepts on
                     performing separate EAP authentication for NAP
                     and ISP."

In Section 9.3.3, change

from:

"
      PANA-Start-Request ::= < PANA-Header: 2, REQ >
                    [ Cookie ]
                  * [ AVP ]
"

to:

"
      PANA-Start-Request ::= < PANA-Header: 2, REQ >
                    [ Cookie ]
		    [ NAP-Information ]
                  * [ ISP-Information ]
                  * [ AVP ]
"

In Section 9.3.4, change

from:

"     PANA-Start-Answer ::= < PANA-Header: 3 >
                    [ Cookie ]
                  * [ AVP ]"

to:

"     PANA-Start-Answer ::= < PANA-Header: 3 >
                    [ Cookie ]
                    [ ISP-Information ]
                  * [ AVP ]"

In section 9.3.5, change

from:

"     PANA-Auth-Request ::= < PANA-Header: 4, REQ >
                    < Session-Id >
                    < EAP-Payload >
                  * [ AVP ]
                0*1 < MAC >"

to:
                                                                            
"     PANA-Auth-Request ::= < PANA-Header: 4, REQ >
                    < Session-Id >
                    < EAP-Payload >
                0*1 [ NAP-Information ]
                0*1 [ ISP-Information ]
                  * [ AVP ]
                0*1 < MAC >

      (Both NAP-Information and ISP-Information MUST NOT be included
       at the same time)"

Add the following sections:

"9.4.9 NAP-Information AVP

The NAP-Information AVP (AVP Code: 1029) is of type Grouped, and
contains zero or one globally unique identifier of the NAP in a
Provider-Identifier AVP and one enterprise name of the NAP in a
Provider-Name AVP.  Its Data field has the following ABNF grammar:

      NAP-Information ::= < AVP Header: 1029 >
                        0*1{ Provider-Identifier }
                           { Provider-Name }
                         * [ AVP ]

9.4.10 ISP-Information AVP

The ISP-Information AVP (AVP Code: 1030) is of type Grouped, and
contains one globally unique identifier of the ISP in a
Provider-Identifier AVP and one enterprise name of the ISP in a
Provider-Name AVP.  Its Data field has the following ABNF grammar:

      ISP-Information ::= < AVP Header: 1030 >
                           { Provider-Identifier }
                           { Provider-Name }
                         * [ AVP ]

9.4.11 Provider-Identifier AVP 

The Provider-Identifier AVP (AVP Code: 1031) is of type Unsigned32,
and contains an IANA assigned "SMI Network Management Private
Enterprise Codes" [IANAWEB] value, encoded in network byte order.

9.4.12 Provider-Name AVP 

The Provider-Name AVP (AVP Code: 1032) is of type UTF8String, and
contains the UTF8-encoded name of the provider."

----
Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana