[tcpm] Universal Session Protocol

[Jonathon Anderson <[e-mail]>]

I am submitting this as a suggested line of research and an offer for collaboration, if it's considered worthwhile. I believe that I have developed a layer 5 protocol that will greatly improve functionality at and between layers 4, 5, and 7, providing numerous efficiency and security benefits. In order to work, it would require a change to TCP that would appreciably alter how the internet is constructed today, although the change itself is rather minor. I'm calling the layer 5 protocol the "Universal Session Protocol" (USP). This is my first draft, so I'm sure there is a lot to do here, and my first submission to IETF, so it would be great to work with someone who knows the process.

My background is 15 years in network and system administration / engineering, and I'm currently studying for my masters in computer science. The only network stack development I've done is creating a TCP stream from an example in a book, so I don't understand the inner workings of TCP enough to elaborate what changes would need to be made; just enough to grasp the fundamentals. That being said, I believe the principles are sound at a high conceptual level.

I am reluctant to submit this because I understand the implications of suggesting a change to one of the foundational protocols of the internet. However, every time I walked away from this I cam back with another justification as to why this was a good idea, and after a challenge session from a good friend we both came to the conclusion that there may be something here. So, I hope that you enjoy it, and I look forward to any responses.

-------------------------------------

Client Overview
1. Client program tells operating system it wants to make an HTTP request to a remote host
2. Operating system creates TCP stream to remote host (using stream ID's, not ports)
3. Operating system creates USP session and determines if HTTP is offered as an application
4. If HTTP is not offered but authentication is, attempt to authenticate and check for HTTP again
5. If HTTP is offered as a service, create a new TCP connection and submit application token to establish an HTTP session (using stream ID's, not ports)
6. Operating system passes TCP stream into client

Server Overview
1. Operating system receives TCP request from remote host and creates TCP stream (using stream ID's, not ports)
2. Operating system sends USP application menu to remote host, offering authentication if available
3. If the remote host requests authentication, complete authentication and send the new application menu
4. If the remote host requests an application, send an application token that grants the remote host permission to connection to specified application
5. When remote host requests new TCP stream and sends USP request with application token, operating system creates a new TCP stream (using stream ID's, not ports)
6. Operating system starts application and passes stream object into server program via IPC (each token is locally associated with an application and parameters)

High Level Benefits
- Eliminate port scanning
- Prevent applications from becoming bots
    - Hosts can't create arbitrary TCP streams
    - OS can rate limit connection creation
    - OS itself would be the only target to make a bot
- Possibility to create third party connection brokers for the application layer
- Detangle layer 7 and layer 4 configurations
- True separation of responsibilities
- Uses object capability model
  - Actions on streams can only be performed if the associated function is provided on the stream object
  - Runaway programs cannot create TCP connections at will to flood remote targets
- Dynamic changes to offered services without needing to manage port allocations
- Authentication before being granted access to protocol
- Can establish multiple sessions simultaneously
- Better isolation because applications will not be required to serve multiple streams in the same process
- Improved confidentiality because all TCP streams are encrypted by default, without PKI
- Improved accountability because every application session can be tied to an authorization token and ultimately to a requestor
    - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet

Detailed Analysis
1. (TCP) Initiate Session
  - No port numbers
  - Client sends it's own dynamically generated TCP stream ID with request
  - Server accepts request and responds with own generated TCP stream ID
  - No longer use ip:port pairs as identifiers
  - Connections identified by client_ip:client_tcp_stream <-> server_ip:server_tcp_stream
  - Removing port information here eliminates encoding of layer 7 information into layer 4 configurations and vice versa It also improves scalability by elimination constraints on available port numbers, and removes a configuration concern from system administration, which reduces the possibility of errors and vulnerabilities.

2. (TCP) Encrypt all sessions
  - Encryption of streams should be default, as a matter of principal
  - Diffie-Hellman is capable of establishing secure channels without PKI
  - PKI is currently used to validate the identity of the cryptographic primitives being exchanged
  - Instead, a secure channel can be built and PKI can be used to verify identity after that, as part of the authentication option detailed below
  - Caeser had his data ciphered and then signed it with his seal. He did not brand his cryptographer and then assume all data that was produced bore his identity, however hilarious and entirely disturbing that would be...

3. (USP) Client Request - Initial request
  - Required Fields
    - "client_session_id"
    - "authorization_token"
    - "application_session"
      - "token"
      - "action"
  - Field Meaning
    - "client_session_id"
      - Unique session identifier created by client
    - "authorization_token"
      - Auth token provided after completing the client chosen authentication process
    - "application_session"."token"
      - Provided by server after service negotiation
      - Required to connect to application
    - "application_session"."action"
      - "begin"
      - "end"
      - "<any other value available from application protocol>"
  - {
      "client_session_id":"<some id>",
      "authorization_token":"<NULL or SOME TOKEN>",
      "application_session": NULL OR {
        "token":"<NULL or some ID>",
        "action":"<begin/end/other>"
      }
    }

4. (USP) Server Response
  - If "application_session" is NULL
    - If "authorization_token" is NULL: Offer unauthenticated menu
    - If "authorization_token" is invalid: Terminate the session with an error
    - If "authorization_token" is valid: Offer authenticated menu
  - If "application_session" is populated
    - Validate that application session token is valid for the requesting IP
      - If a third party is allowed to specify a client IP for the application, and that IP is associated with the token, then a brokering host could establish connections for arbitrary clients, if authorization between client and broker has occurred. (See request body details below.)
    - Begin application associated with token
      - Maintaining a token to application mapping will permit the menu to change on the fly
    - Ignore "authorization_token" as it's only meant for menu access

4.a.i. (USP) Application Menu
  - Required fields
    - "server_session_id"
    - "application_menu"
      - "name"
      - "expected_request_body"
  - Field Meaning
    - "name"
      - human readable name
      - I can see a scenario where human readable identifiers would no longer be relevant, as the general trend is to remove constructs from applications that require human reasoning and intervention. However, for the time being all existing application layer protocols are identified with human readable names, and changing this in a revision would not be difficult, so it seems safe to require for the time being.
    - "server_session_id"
      - Unique session identifier created by server
    - "application_menu"
      - numerically indexed
      - JSON
      - Index 0 is reserved as authentication initiation if not authenticated yet
      - Index 0 is reserved as token invalidation if already authenticated
      - The benefit of providing a separate list after authentication is that secure applications remain unknown AND unavailable until after authentication occurs. So, for example, instead of SSH being available for everyone and fighting off authentication and protocol attacks on its own, availability of the SSH service could not be be known much less a connection established because the index would not be known and the server would not have responded with the necessary connection information. This would provide an enormous amount of security by placing potential flawed protocols behind the authentication wall instead of in front of it.
      - Another way to look at the previous benefit is that "port scanning", or "scanning listening applications and attempting to exploit protocol vulnerabilities", will be significantly reduced
      - Index 0 is a JSON array containing authentication methods with parameters
      - There is no association between index numbers and layer 7 applications
      - Application menu SHOULD be built dynamically
        - Installed applications SHOULD register their parameters with the operating system in a place that can be read by UAP
        - Available authentication methods SHOULD also be registered with parameters
        - USP SHOULD allow configurations of registry path
        - If registration is used
          - Registry SHOULD provide "expected_request_body"
          - Empty fields representing the expected structure of a request for that application
      - "expected_request_body"
        - Lays out the expected structure of the application connection request
        - If an IP is accepted as a connection parameter, the brokering host could request an "application_session"."token" and pass it back to the client host. When the client host makes a request to the server host, the token will match the IP that was provided in the request body. "Connection brokering" could be a service that's offered after authentication to ensure brokering hosts are not abused. Clients will not receive unsolicited attempts to force them to connect to servers because they won't be listening for this traffic. A client must initiate the brokering service.
  - {
  "server_session_id":"<some session id>",
  "application_menu": {
    "0": [
      {
        "auth_method1":"auth_method_name_or_id1",
        "auth_field1":"auth_value1",
        "auth_field2":"auth_value2",
        "expected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
      },
      {
        "auth_method":"auth_method1",
        "auth_field1":"auth_value1",
        "auth_field2":"auth_value2",
        "expected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
      }
    ],
    "1": {
      "name":"app1",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
        "ecpected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
    },
    "2": {
      "name":"app2",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
        "expected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
    },
    "3": {
      "name":"app3",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
        "expected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
    },
    "4": {
      "name":"app4",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
        "expected_request_body":{
          "required_field1":"",
          "required_field2":""
        }
    }
  }
}

4.a.ii. (USP) Client Request
  - Required Fields
    - "client_session_id"
    - "authorization_token"
    - "requested_services"
      - If requestng services or authorization: Request body required fields as defined in application menu
      - If index 0 is being used to invalidate tokens: An array of tokens

  - Client may request multiple services in the same request body to establish multiple sessions simultaneously, including starting the authentication process while simultaneously acknowledging other valid service requests by sending an application session token for each service
  - {
  "client_session_id":"<some id>",
  "authorization_token":"<NULL or SOME TOKEN>",
  "requested_services": {
    "0": { (if requesting authentication)
        "required_field1":"required_value1",
        "required_field2":"required_value2"
    },
    "0": [ (if invalidating tokens)
        "token1",
        "token2"
    ],
    "1": {
        "required_field1":"required_value1",
        "required_field2":"required_value2"
    },
    "3": {
        "required_field1":"required_value1",
        "required_field2":"required_value2"
    }
  }
}

4.a.iii. (USP) Server Response
  - Authentication
    - If request is made for authentication, initiate authentication process
    - Ending by providing "authorization_token"

  - Requested Services
    - For each valid and authorized service, generate and respond with token that will be used as "application_session"."token" by client

  - Authorization
    - If "authorization_token" is NULL:
      - Respond to secure application requests with error
      - Complete session establishment for valid public application requests
    - If "authorization_token" is invalid:
      - Respond to secure application requests with error
      - Complete session establishment for valid public application requests
    - If "authorization_token" is valid: Complete session establishment for all valid requests

    - {
        "1": {
          "token":"<some token>"
        },
        "3": {
          "token":"<some token>"
        },
        "5": {
          "error":{
            "message":"Authorization token missing"
          }
        },
        "7": {
          "error":{
            "message":"Authorization token invalid"
          }
        }
      }

4.b. Application Initialization
  - If the client request as a valid application session token, initialize the desired application and pass the TCP stream into the application using IPC
  - Server applications are no longer responsible for creating their TCP connections, alleviate application programmers from needing to manage system functions
  - Server applications can be prevented from arbitrarily creating TCP connections, making it impossible for applications to become bots.
  - Instead of creating server applications that manage multiple streams internally, lightweight applications could be started. This would provide better process isolation. It's likely we don't do this now because it's impossible with the limit on the number of ports available. There is no restriction on the number of session ID's, like there is on ports, so again the only restriction is available resources
  - Because authentication can be a requirement for access to the application itself, it can be tied directly back to a user
    - Every application session can require an application token
    - Every application token can be associated with an authorization token (permission to view the application in the menu)
    - Every authorization token can be associated with an identity provided to the authentication server
    - Every authorization token can also be logged by the client operating system and associated with a user identity
    - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet

Sent with [ProtonMail](https://protonmail.com/) Secure Email.