My first time sending a message to a partner via OFTP failed.。Session Termination [SINO-WMB] ("Invalid Challenge Response", internal code 11). Please technical support to help me analyze what caused this status error
Details could be found in section 4.2.4 of the RFC:
1. Initiator -- SECD ------------> Responder Change Direction
<------------ AUCH -- Challenge
-- AURP ------------> Response
<------------ SECD -- Change Direction
-- AUCH ------------> Challenge
<------------ AURP -- Response
The Initiator sends a Security Change Direction (SECD) to which the
Responder replies with an Authentication Challenge (AUCH).
The Responder looks up the public certificate that is linked to the
purported identity of the Initiator (located in the SSID). If the
Responder is unable to locate a suitable certificate then
authentication fails. The Responder uses the public key contained in
the certificate to encrypt a random challenge, unique for each
session, for the Initiator. This encrypted challenge is sent as a
[CMS] envelope to the Initiator as part of the AUCH.
The Initiator decrypts the challenge using their private key and
sends the decrypted challenge back to the Responder in the
Authentication Response (AURP).
The Responder checks that the data received in the AURP matches the
random challenge that was sent to the Initiator.
If the data matches, then the Initiator has authenticated
successfully and the Responder replies with a Security Change
Direction (SECD) beginning the complementary process of verifying the
Responder to the Initiator. If the data does not match, then the
Initiator fails authentication.
-- and this is what happens, the challenge failed.
In section 5.2.3 you will find the definition of the SSID, where the secure authentication is set. If both of you and your partner disable it in their system there will be no secure authentication mechanism as additional session security.
This is the protocol message:
o-------------------------------------------------------------------o
| SSID Start Session |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSIDCMD | SSID Command 'X' | F X(1) |
| 1 | SSIDLEV | Protocol Release Level | F 9(1) |
| 2 | SSIDCODE | Initiator's Identification Code | V X(25) |
| 27 | SSIDPSWD | Initiator's Password | V X(8) |
| 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) |
| 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) |
| 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) |
| 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) |
| 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) |
| 44 | SSIDCRED | Credit | V 9(3) |
| 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) |
| 48 | SSIDRSV1 | Reserved | F X(4) |
| 52 | SSIDUSER | User Data | V X(8) |
| 60 | SSIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
- its the field SSIDAUTH which can be controled by the connection settings of the related partner in the mendelson OFTP2 partner management.
This is the field description of the RFC:
SSIDAUTH Secure Authentication Character
Value: 'Y' The location requires secure authentication. 'N' The
location does not require secure authentication.
Secure authentication is only used if agreed by both
locations.
If the answer of the Responder does not match with the
authentication requirements of the Initiator, then the
Initiator must abort the session.
No negotiation of authentication is allowed.
authentication p -- SSID ------------>
<------------ SSID -- authentication q
p == q -> continue.
p != q -> abort.
As the OFTP2 RFC is mainly the description of a state machine you can always see what happens if you debug the state machine using the "state machine" log settings:
The following states are important regarding this issue:
WF_AUCH Wait for Authentication Challenge
The Speaker has sent a Security Change Direction (SECD)
command and must wait for Authentication Challenge (AUCH)
from the Listener.
WF_AURP Wait for Authentication Response
The Speaker has sent an Authentication Challenge (AUCH)
command and must wait for Authentication Response (AURP)
from the Listener.
- in section [9.8.1. State Table] of the RFC you see the defined behavior and followup states for these states.
Comments
Hello, this is from a…
Submitted by service on Wed, 03/11/2020 - 08:55
Hello,
this is from a technical perspective part of the following OFTP2 protocol messages:
AUCH Authentication Challenge
AURP Authentication Response
- please refer to https://tools.ietf.org/html/rfc5024 for further information.
Details could be found in section 4.2.4 of the RFC:
1. Initiator -- SECD ------------> Responder Change Direction
<------------ AUCH -- Challenge
-- AURP ------------> Response
<------------ SECD -- Change Direction
-- AUCH ------------> Challenge
<------------ AURP -- Response
The Initiator sends a Security Change Direction (SECD) to which the
Responder replies with an Authentication Challenge (AUCH).
The Responder looks up the public certificate that is linked to the
purported identity of the Initiator (located in the SSID). If the
Responder is unable to locate a suitable certificate then
authentication fails. The Responder uses the public key contained in
the certificate to encrypt a random challenge, unique for each
session, for the Initiator. This encrypted challenge is sent as a
[CMS] envelope to the Initiator as part of the AUCH.
The Initiator decrypts the challenge using their private key and
sends the decrypted challenge back to the Responder in the
Authentication Response (AURP).
The Responder checks that the data received in the AURP matches the
random challenge that was sent to the Initiator.
If the data matches, then the Initiator has authenticated
successfully and the Responder replies with a Security Change
Direction (SECD) beginning the complementary process of verifying the
Responder to the Initiator. If the data does not match, then the
Initiator fails authentication.
-- and this is what happens, the challenge failed.
In section 5.2.3 you will find the definition of the SSID, where the secure authentication is set. If both of you and your partner disable it in their system there will be no secure authentication mechanism as additional session security.
This is the protocol message:
o-------------------------------------------------------------------o
| SSID Start Session |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSIDCMD | SSID Command 'X' | F X(1) |
| 1 | SSIDLEV | Protocol Release Level | F 9(1) |
| 2 | SSIDCODE | Initiator's Identification Code | V X(25) |
| 27 | SSIDPSWD | Initiator's Password | V X(8) |
| 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) |
| 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) |
| 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) |
| 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) |
| 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) |
| 44 | SSIDCRED | Credit | V 9(3) |
| 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) |
| 48 | SSIDRSV1 | Reserved | F X(4) |
| 52 | SSIDUSER | User Data | V X(8) |
| 60 | SSIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
- its the field SSIDAUTH which can be controled by the connection settings of the related partner in the mendelson OFTP2 partner management.
This is the field description of the RFC:
SSIDAUTH Secure Authentication Character
Value: 'Y' The location requires secure authentication. 'N' The
location does not require secure authentication.
Secure authentication is only used if agreed by both
locations.
If the answer of the Responder does not match with the
authentication requirements of the Initiator, then the
Initiator must abort the session.
No negotiation of authentication is allowed.
authentication p -- SSID ------------>
<------------ SSID -- authentication q
p == q -> continue.
p != q -> abort.
As the OFTP2 RFC is mainly the description of a state machine you can always see what happens if you debug the state machine using the "state machine" log settings:
The following states are important regarding this issue:
WF_AUCH Wait for Authentication Challenge
The Speaker has sent a Security Change Direction (SECD)
command and must wait for Authentication Challenge (AUCH)
from the Listener.
WF_AURP Wait for Authentication Response
The Speaker has sent an Authentication Challenge (AUCH)
command and must wait for Authentication Response (AURP)
from the Listener.
- in section [9.8.1. State Table] of the RFC you see the defined behavior and followup states for these states.
Regards