Details

    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      Current parsec implementation decription has many steps :

      1. server send an Initial handshake packet
      2. Client send an Handshake response packet.
      3. receiving an Authentication Switch Request packet with 'parsec' plugin type with a 32-byte server random scramble
      4. if the ext-salt was specified in the .my.cnf, the client skips go to step 6, otherwise it sends the user name (and nothing else) to the server
      5. Server sends the ext-salt to the client
      6. Client sends the random 32-byte scramble, and the concat(server scramble, client scramble) ed25519-signed by a secret key generated from the PBKDF2(password, ext-salt)
      7. Server replies with "ok" or "acces denied"

      most connectors are using pool configured, with one user, and ext-salt is fixed for a user ( until password change), so for any new connection, after a successful authentication, ext-salt can be cached.

      Sending an empty packet requesting to ext-salt is actually mandatory: if ext-salt is known by connector, and go directly to step 6, connection fails.

      second point concerns when https://jira.mariadb.org/browse/MDEV-12320 default authentication permitting parsec will be done:
      if connector cache the ext-salt that is specific to the user, exchanges can be faster :

      1. server send an Initial handshake packet with 'parsec' default authentication and 32-byte server random scramble
      2. Client can directly send the random 32-byte scramble, and the concat(server scramble, client scramble) ed25519-signed by a secret key generated from the PBKDF2(password, ext-salt)
      3. Server replies with "ok" or "acces denied"

      Attachments

        Issue Links

          Activity

            Hi diego dupin!

            > Sending an empty packet requesting to ext-salt is actually mandatory

            I think this packet sends the user name (Handshake Response Packet). The ext-salt is per-user unique, so we cannot send it before.

            What we can do is to fetch the (manually stored) ext-salt from the config file, and use it to provide the response yet in Handshake Response Packet.

            Theoretically, we can reduce roundtrips significantly, but for that we have to rewrite the whole protocol (the client doesn't have to wait for server's initial packet to send a user name [if the SSL key is known to this moment]), and even better to get rid of TCP.

            nikitamalyavin Nikita Malyavin added a comment - Hi diego dupin ! > Sending an empty packet requesting to ext-salt is actually mandatory I think this packet sends the user name ( Handshake Response Packet ). The ext-salt is per-user unique, so we cannot send it before. What we can do is to fetch the (manually stored) ext-salt from the config file, and use it to provide the response yet in Handshake Response Packet . Theoretically, we can reduce roundtrips significantly, but for that we have to rewrite the whole protocol (the client doesn't have to wait for server's initial packet to send a user name [if the SSL key is known to this moment] ), and even better to get rid of TCP.

            People

              nikitamalyavin Nikita Malyavin
              diego dupin Diego Dupin
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.