Subject: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server

From: Pete McCann <[email-masked]>
Date: Wed, 27 Mar 2002 11:59:02 -0600 (CST)

Issue:                    Bug in Acct state machine + State machines
                          should be split into client vs. server
Submitter name:           Pete McCann
Submitter email address:  [email-masked]
Date first submitted:     03-27-2002
Reference:
Document:                 diameter-base-09
Comment type:             Technical
Priority:                 S
Section:                  8.1, 8.2

Rationale:

Currently, there is no way to enter the PendingI state in the accounting state
machine.  This is a bug.

The state machines given in the diameter base document are confusing
to read, because they mix client and server states.

Requested Change:

Split each machine in two, and replace 8.1 and 8.2 with the following
text.  Note the addition of an event to the client accounting state
machine to enter the PendingI state:

8.1  Authorization Session State Machine

   This section contains a set of finite state machines, representing the life
   cycle of Diameter sessions, and which MUST be observed by all Diameter
   implementations that make use of the authentication and/or
   authorization portion of a Diameter application. The term Service-
   Specific below refers to a message defined in a Diameter application
   (e.g. Mobile IP, NASREQ).

   There are four different authorization session state machines
   supported in the Diameter base protocol. The first two describe a
   session in which the server is maintaining session state, indicated
   by the value of the Auth-Session-State AVP (or its absence).  One
   describes the session from a client perspective, the other from a
   server perspective. The second two state machines are used when
   the server does not maintain session state. Here again, one
   describes the session from a client perspective, the other from a
   server perspective.

   When a session is moved to the Idle state, any resources that were
   allocated for the particular session must be released.  Any event not
   listed in the state machines MUST be considered as an error
   condition, and an answer, if applicable, MUST be returned to the
   originator of the message.

   The following state machine is observed by a client when state is
   maintained on the server:

                              CLIENT, STATEFUL
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or Device Requests      send       Pending
                access                         service
                                               specific
                                               auth req

      Pending   Successful Service-specific    Grant      Open
                authorization answer           Access
                received with default
                Auth-Session-State value

      Pending   Successful Service-specific    Sent STR   Discon
                authorization answer received
                but service not provided

      Pending   Error processing successful    Sent STR   Discon
                Service-specific authorization
                answer

      Pending   Failed Service-specific        Cleanup    Idle
                authorization answer received

      Open      user or client device          send       Open
                requests access to service     service
                                               specific
                                               auth req

      Open      Successful Service-specific    Extend     Open
                authorization answer received  Answer

      Open      Accounting message sent        process    Open

      Open      Failed Service-specific        Discon.    Idle
                authorization answer           user/device
                received.

      Open      Session-Timeout Expires on     send STR   Discon
                Access Device

      Open      ASR Received                   send ASA,  Discon
                                               STR

      Open      Authorization-Lifetime +       send STR   Discon
                Auth-Grace-Period expires on
                access device

      Discon    ASR Received                   None       Discon

      Discon    STA Received                   Discon.    Idle
                                               user/device

   The following state machine is observed by a server when it is
   maintaining state for the session:

                             SERVER, STATEFUL
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Service-specific authorization send       Open
                request received, and          successful
                user is authorized             serv.
                                               specific answer

      Idle      Service-specific authorization send       Idle
                request received, and          failed serv.
                user is not authorized         specific answer

      Open      Service-specific authorization send       Open
                request received, and user     successful
                is authorized                  serv. specific
                                               answer

      Open      Service-specific authorization send       Idle
                request received, and user     Failed serv.
                is not authorized              specific
                                               answer,
                                               Cleanup

      Open      Accounting message received    process    Open

      Open      Home server wants to           send ASR   Open
                terminate the service

      Open      ASA Received                   Cleanup    Idle
                with Result-Code
                = UNKNOWN-SESSION-ID

      Open      ASA Received                   None       Open
                with Result-Code               (ignore)
                not = UNKNOWN-SESSION-ID

      Open      Authorization-Lifetime (and    Cleanup    Discon
                Auth-Grace-Period) expires
                on home server.

      Open      Session-Timeout expires on     Cleanup    Discon
                home server

      Open      STR Received                   Send STA   Idle

      Not       ASA Received                   None       No Change.
      Open

      Discon    STR Received                   Send STA   Idle

   The following state machine is observed by a client when state is
   not maintained on the server:

                              CLIENT, STATELESS
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or Device Requests      send       Pending
                access                         service
                                               specific
                                               auth req

      Pending   Successful Service-specific    Grant      Open
                authorization answer           Access
                received with Auth-Session-
                State set to
                NO_STATE_MAINTAINED

      Pending   Failed Service-specific        Cleanup    Idle
                authorization answer
                received

      Open      Accounting message sent        process    Open

      Open      Session-Timeout Expires on     Discon.    Idle
                Access Device                  user/device

      Open      Service to user is terminated  Discon.    Idle
                                               user/device

   The following state machine is observed by a server when it is not
   maintaining state for the session:

                              SERVER, STATELESS
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Service-specific authorization send serv. Open
                request received, and          specific
                successfully processed         answer

      Open      Accounting message received    process    Open

8.2  Accounting Session State Machine

   For applications that only require accounting services, the following
   state machines MUST be supported.  The first is to be observed by
   clients, the second by servers.

   When a session is moved to the Idle state, any resources that were
   allocated for the particular session must be released.  Any event not
   listed in the state machines MUST be considered as an error
   condition, and an answer, if applicable, MUST be returned to the
   originator of the message.

                            CLIENT, ACCOUNTING
      State     Event                          Action     New State
      -------------------------------------------------------------
      Idle      Client or device requests      send       PendingS
                access                         accounting
                                               start req.

      Open      Interim interval elapses       send       PendingI
                                               accounting
                                               interim
                                               record

      Idle      Client or device requests      send       PendingE
                a one-time service             accounting
                                               event req

      Idle      Records in storage             Send       PendingB
                                               record

      Open      User service terminated        send       PendingL
                                               accounting
                                               stop req.

      PendingS  Successful accounting                     Open
                start answer received

      PendingS  Failure to send and buffer     Store      Open
                space available and realtime   Start
                not equal to DELIVER_AND_GRANT Record

      PendingS  Failure to send and no buffer             Open
                space available and realtime
                equal to GRANT_AND_LOSE

      PendingS  Failure to send and no buffer  Disconnect Idle
                space available and realtime   user/dev
                not equal to
                GRANT_AND_LOSE

      PendingI  Failure to send and (buffer    Store      Open
                space available or old record  Interim
                can be overwritten) and        Record
                realtime not equal to
                DELIVER_AND_GRANT

      PendingI  Failure to send and no buffer             Open
                space available and realtime
                equal to GRANT_AND_LOSE

      PendingI  Failure to send and no buffer  Disconnect Idle
                space available and realtime   user/dev
                not equal to GRANT_AND_LOSE

      PendingE  Successful accounting                     Idle
                event answer received

      PendingE  Failure to send and buffer     Store      Idle
                space available                Event
                                               Record

      PendingE  Failure to send and no buffer             Idle
                space available

      PendingB  Successful accounting answer   Delete     Idle
                received                       record

      PendingB  Failure to send                           Idle

      PendingL  Successful accounting                     Idle
                stop answer received

      PendingL  Failure to send and buffer     Store      Idle
                space available                Stop
                                               Record

      PendingL  Failure to send and no buffer             Idle
                space available

                            SERVER, ACCOUNTING
      State     Event                          Action     New State
      -------------------------------------------------------------

      Idle      Accounting start request       send       Open
                received, and successfully     accounting
                processed.                     start
                                               answer

      Idle      Accounting event request       send       Idle
                received, and successfully     accounting
                processed.                     event
                                               answer

      Open      Receive Interim Record         send       Open
                                               accounting
                                               answer

      Open      Accounting stop request        send       Idle
                received, and successfully     accounting
                processed                      stop answer

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Mar 2002 01:44:28 +0200

Hi,

On my way to the IETF I I decided to try and read the CMS document well
once more. I have only now found the time to send this e-mail about some
suggestions I have. Feel free to use these suggestions or discard them
if you don't agree... note that there's also a related clarification to
base. And I'm proposing some modifications to the AVP occurrence rules
in CMS so some of this borders on a technical issue.

Jari
----
Issue:                    CMS editorial issues
Submitter name:           Jari Arkko
Submitter email address:  [email-masked]
Date first submitted:     03-27-2002
Reference:
Document:                 cms-09, base-09
Comment type:             Editorial
Priority:                 S
Section:                  CMS: Abs, ToC, 1, 2, 3, 4, 5, Base: 4.6
Rationale:

1) In the abstract "... perform message routing, and other
than routing AVPs, do not modify Diameter messages." =>
"... perform message routing and do not modify Diameter
messages beyond routing AVPs."

2) ToC and the document structure. I would suggest
the following modifications:
- Since terms generally need to introduced before they are
   used, 1.1 needs to move to its own chapter before chapter 1.
- I would add a Terms section. See attached file for initial
   text.
- I would name 2.0 "AVP Protection' and place current 2.0 under
   it as '2.1. Format' and 1.7 under it as 2.3. Then I would
   add some clarifying text on exactly what the CMS spec expects
   nodes to do with AVPs (I couldn't find such text before this
   point). See attached second file for initial text.
- I would name 5.0 "Example Message Flow"

3) Chapter 1. Doesn't really describe what the functionality
provided here is, just talks about how it is provided. Suggested
text to add before the third paragraph: "This specification
provides an additional security mechanism to protect transport of
Diameter AVPs through rogue Diameter agents."

4) Chapter 1. "Redirector agent" => "redirect agent" (the term
used in base).

5) Chapter 1.2 last paragraph only talks about signing. Why? I
suggest that we should talk about both signing and encryption.
Here's some proposed text to add at the end: "Similarly, participants
MAY apply encryption to protect one or more AVPs within a message."

6) Chapter 4.6 in base. This is related to the above issue. We
have now clarified very well what MAY ENCR means, but we haven't
done the same for 'MAY Set P Bit'. Essentially, isn't this the same
thing? Propose to add text after first paragraph of 4.6: "Similarly,
for the originator of a DIameter message, a "P" in the "MAY" column
means that if a message containing that AVP is to be sent
via a proxy/agent then the message MUST NOT be sent unless there
is a DSA between the originator and the recipient or the originator
has locally trusted configuration that indicates  that
CMS need not be used."

7) Chapter 1.3 "reuse the values" -- what values? I think this
is still referring to the old Encrypted-AVPs AVP, or something like
that. Propose to delete the sentence.

8) 1.3, "does not request a DSAR to request a DSA" => "does not request
a DSA through sending a DSAR message"

9) 1.3, "the access device can then determine whether it is willing to
provide service, based on its local policy". I would simply say "The access
device can then determine whether to trust this notification, based
on local configuration i.e. the keys of trusted agents. If the access device
can not trust this notification, it MUST refuse the service in question."

10) 3.1, "... which AVPs should be encrypted, signed or both..." -- remove
this text, but keep the part about the public keys.

11) 3.1. DSA[RA] message contents, doesn't clearly show which AVPs are
used for which purpose, which makes the spec harder to read. Also,
misses some of the AVPs. Proposed text in the third attachment.

12) 4.2 Local-CA-Info appears to be unnecessary. Remove from this
message.

13) 3.2 "capable of acting as recipients for confidentiality" =>
"that support DSAs".

14) 3.3. AES. Replace the current text with "It is strongly recommended
that the AES algorithm is supported where it is available."

15) 4.1 delete the statement about the cert distribution protocol, I don't
think we need to state that.

16) 5.0 delete the text about the bidir signatures and encryption.

17) 5.0 step h,add to the end "Those AVPs that need to be kept confidential
are placed in CMS-Encrypted-AVP in encrypted form. Modify picture accordingly.

18) 5.0 step i. Add before the encryption part "The message includes the
CMS-Signed-AVP, which authenticates the AVPs that need it".

19) 5.0 step h. "that were requested by the Home Server in the DSAA." =>
"that need it".

20) section 4.I think CA-Chain should be a "*" instead of "0*1". THere
may be zero chains, if the roots and the certs don't mix or if the peer
should already know the chain. But there can be multiple chains if several
roots are used.

   CA
      Certificate Authority, a trusted third party
      that signs cryptographic certificates for other
      nodes.

   CMS
      Cryptographic Message Syntax [CMS].

   DSA
      Diameter Security Association.

   OCSP
      Online Certificate Status Protocol [OCSP].

This specification allows both the encryption and signing of
AVPs. Encryption takes place through taking the AVPs that need
protection from the Diameter message and placing them, concatenated
and encrypted, in CMS-Encrypted-Data AVP. The original AVPs are not
retained in the message.

Signing takes place through signing contents of the protected AVPs,
and placing the signature in the CMS-Signed-Data AVP.  The original
AVPs are retained in the message, except in the case where both
encryption and signatures are needed. In this case the CMS-Encrypted-Data
AVP is created first and this is then signed.
   The originating node sends the DSAR message to a server in the
   destination realm. The DSAR message contains:

       - TTL for this DSA (seconds) in the DSA-TTL AVP.

       - The realm part of the user's NAI in the Destination-Realm AVP.

       - The list of direct trust CA's that the originating Diameter
         node has configured into it for certificate validation.  A
         "direct trust" CA is one that the node is willing to use as the
         "top" of a certificate chain, sometimes confusingly known as a
         "root CA". The list is given in a sequence of Local-CA-Info
         AVPs.

       - Certificate chains from each direct trust CA, in a sequence
         of CA-Chain AVPs. One AVP value is needed for each direct trust
         CA. A value MAY be omitted when the peers know that the
         relevant chains already exist at the other side.

       - Public key certificates for the Diameter servers in the
         sending realm, all of which MUST validate up to one of the
         CAs above, via the chain of CA certificates above.
         
       - A flag indicating whether the originating Diameter node wishes
         to receive certificate status information using OCSP messages.
         If this flag requires a fresh OCSP response, a nonce to be used
         by the destination Diameter node in OCSP requests MUST also be
         supplied. See [OCSP] for more details on the certificate status
         protocol and messages. The flag is given in the OCSP-Request-Flags
         AVP.

       - Optional nonce for OCSP, in the OCSP-Nonce AVP.

       - The DSAR message MAY include the CMS-Signed-Data AVP. If the
         originating node has a private key, and it includes AVPs
         whose 'P' bit are set, the CMS-Signed-Data AVP MUST be
         present.

   The destination node MUST check that the provided elements of the
   DSAR are valid. It MUST check, at least, that:

      - Its local policy allows the given TTL, realm,
        certification status, and other parameters.
      - A common "top" of the certificate chain can be found between the
        home and foreign domains.
      - This certificate chain is cryptographically correct, passes 
        the (relevant parts of the) path validation algorithm specified
        in [CERTPROF] and terminates at a CA mentioned in the DSAR message
      - The certificate chain between the "top" certificate and
        the certificate in the AAA-Node-Cert AVP can be cryptographically
        verified.
      - The signature, if any, can be verified.

   If these conditions can not be verified, the destination node MUST
   return a DSAA with the Result-Code AVP set to
   DIAMETER_NO_DSA_ESTABLISHED.

   In the event the DSAR requested OCSP validation, via the OCSP-
   Request-Flags AVP, and OCSP is not locally supported, the DSAA MUST
   be returned with the Result-Code AVP set to
   DIAMETER_OCSP_NOT_SUPPORTED.

   Otherwise, the destination node returns the DSAA message which
   contains:

       - TTL for this DSA (seconds), in the DSA-TTL AVP.

       - One or more chains of certificates from the "top" CAs in the
         DSAR message to the certificates of this node. Each chain
         appears as a CA-Chain AVP.

       - Public key certificates for the Diameter servers in the realm
         that sends the DSAA message. All the certificates MUST
         validate up to one of the CAs in the DSAR message, via the
         chain of CA certificates above.

       - Optionally, if OCSP an response was requested in the DSAR and
         OCSP is supported, a list of OCSP responses for the
         certificates in question. If a fresh response was required
         and a nonce value was included, each response will contain
         the nonce from the DSAR message

       - The DSAA MUST include the CMS-Signed-Data, signed by a
         Diameter agent or server within the user's realm, to prevent
         an intermediate node from falsely claiming that the DSA has
         been established.

   The originating Diameter node MUST check that the provided elements
   of the DSAR are valid. Any failure results in silently discarding
   the DSAA message, auditing the event and not sending the original
   Diameter message that requested protection from a DSA. It MUST
   check, at least, that:

       - the certificate chain provided in the DSAA is cryptographically
         correct, passes the (relevant parts of the) path validation
         algorithm specified in [CERTPROF] and terminates at a CA
         mentioned in the DSAR message
       - the name in the certificate is consistent with the rules
         detailed in section 3.2.
       - the DSAA message MUST include the CMS-Signed-Data AVP, the
         signature MUST be validated and the signer's certificate chain
         MUST terminate as a CA mentioned in the DSAR message
       - the expiration of the TTL MUST be less or equal to the earliest
         expiration of all certificates in the message, encoded in the
         notAfter field.

   If the initiator's policy is such that certificate status is
   required, it MAY indicate that it requires an OCSP response from the
   DSA peer in the DSAA message, via the OCSP-Request-Flags AVP.
   Further, the initiator MAY request that the OCSP response be fresh
   (non-cached) via the OCSP-Request-Flags and OCSP-Nonce AVPs. Upon
   receipt of a DSAR message requesting an OCSP response, the receiver
   issues an OCSP request and returns the response within the DSAA
   message's OCSP-Responses AVP. The sender of the DSAA MAY included a
   cached OCSP response, unless the requestor specifically requested a
   fresh response.

   The nonce value is to be (the beginning of) the nonce in the OCSP
   response. The reason for this is that the responder MAY add
   additional bits to the nonce, but the nonce provided in the OSCP-
   Nonce MUST be present at the beginning of the nonce of the OSCP
   response.

   If certificate revocation is enabled, anytime a certificate is used
   from the local certificate cache, a revocation check MUST be
   performed.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Mar 2002 15:24:05 -0800 (PST)

Assigned issue #316.

---

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 29 Mar 2002 12:16:13 -0500

Hi Pete and John,

Here's some feedback.  I think Pete's cutting and pasting was perfect.
When reviewing the state tables, I've suggested some new changes which I
hope are improvements, but if you think it is too late for these
changes, then just disregard them.

Bob K.

>       State     Event                          Action     New State

I think you might want to split the above "ASR Received" event
into three events, making the client's state machine more
consistent with the Server's state machine and with the base
protocol text; i.e.

        Idle      ASR Received                   send ASA   Idle
                  for unknown session            with
                                                 Result-Code
                                                 = UNKNOWN-
                                                 SESSION-ID

        Open      ASR Received,                  Send ASA   Discon
                  client will comply with        with
                  request to end the session     Result-Code
                                                 = SUCCESS.
                                                 Send STR.

        Open      ASR Received,                  Send ASA   Open
                  client will not comply with    with
                  request to end the session     Result-Code
                                                 != SUCCESS.

>       Discon    ASR Received                   None       Discon

Shouldn't the above be:

        Discon    ASR Received                   Send STA.  Discon

>       State     Event                          Action     New State

I think going to Idle is more appropriate above, because the server
may not be receiving an STR from the client, i.e.

        Open      Authorization-Lifetime (and    Cleanup    Idle
                  Auth-Grace-Period) expires
                  on home server.

>       Open      Session-Timeout expires on     Cleanup    Discon

I think going to Idle is more appropriate above, because the server
may not be receiving an STR from the client, i.e.

        Open      Session-Timeout expires on     Cleanup    Idle
                  home server

>       Open      STR Received                   Send STA   Idle

I'd add a "cleanup" to the above, i.e.

        Open      STR Received                   Send STA,  Idle
                                                 Cleanup

>       Discon    STR Received                   Send STA   Idle

I'd replace the above by:

        Not Open  STR Received                   Send STA,  Idle
                                                 Cleanup
>       State     Event                          Action     New State

Since the server isn't maintaining session state, I'd
delete the above "SERVER, STATELESS" table altogether.

And then change the 2nd paragraph of the proposed text to say
"three" rather than "four" machines.

>       State     Event                          Action     New State

I have less to offer in terms of the Accounting state machine, but
here's a couple of observations:

1. When in the PendingX states, do you want to add entries for
an "Unsuccessful accounting answer received" event?

2. Do you want to add entries to deal with having to send a Stop
when a Start or Interim is still pending, e.g. something like:

       PendingS  User Service terminated        Send Stop   PendingL

       PendingI  User Service terminated        Send Stop   PendingL