This follows the boundary settled in #28: these are authentication/session
mechanics only. Nothing here writes OCF security resources, selects an OTM,
or persists credentials.
Two gaps remain between the current package and the connection path I have
running against two WD53-family appliances.
1. Learn a verified hardware-certificate UUID during first use
SamsungServerProfile.bound_device() is the right runtime default: it needs a
previously verified certificate UUID and rejects every other leaf. During the
initial manufacturer-certificate flow, though, that UUID is not yet available
to the caller. The appliance presents its Samsung hardware certificate during
the first authenticated DTLS session.
The retained integration code currently does three things on that same live
session:
- verifies the CA chain and the exact Samsung
C / O / OU subject role;
- extracts the non-zero UUID from the verified leaf's common name; and
- binds that certificate UUID to the OCF device identity read from
/oic/d
before the association is persisted.
The certificate UUID and OCF device UUID are separate identities; the code
does not assume that they match. It also does not accept an arbitrary first
certificate. The proposed package API is an explicit first-use profile which
keeps all of the existing chain and role checks, exposes the verified
certificate UUID on the completed session, and retains no learned identity in
the reusable authentication provider. Normal reconnects continue to use
bound_device().
2. Retire an HVR-only half-open peer
On both WD53 appliances, a failed initial handshake can stop after the DTLS
HelloVerifyRequest exchange. The appliance then retains the half-open peer on
that UDP tuple and ignores a clean retry long enough to make setup look
unrecoverable.
The retained integration handles only the narrowly proven transcript: a fixed
non-zero local UDP port, at least two ClientHello records, and inbound
handshake messages consisting only of HelloVerifyRequest. It sends one
epoch-zero fatal handshake_failure alert for that half-open peer and returns
control to the caller, which owns the settle delay and any retry.
I propose keeping this opt-in and fail-closed:
- require a fixed non-zero
local_port;
- retain only bounded handshake metadata, not packet contents;
- emit the alert only when the complete observed transcript matches the
HVR-only shape;
- never retry automatically inside
connect(); and
- raise a distinct redacted session error so the caller can decide whether a
retry is appropriate.
I am splitting these into two small PRs so the identity contract and cleanup
wire behavior can be reviewed independently. A final documentation/API
contract PR can then show the complete supported connection surface without
moving ownership policy into this package.
This follows the boundary settled in #28: these are authentication/session
mechanics only. Nothing here writes OCF security resources, selects an OTM,
or persists credentials.
Two gaps remain between the current package and the connection path I have
running against two WD53-family appliances.
1. Learn a verified hardware-certificate UUID during first use
SamsungServerProfile.bound_device()is the right runtime default: it needs apreviously verified certificate UUID and rejects every other leaf. During the
initial manufacturer-certificate flow, though, that UUID is not yet available
to the caller. The appliance presents its Samsung hardware certificate during
the first authenticated DTLS session.
The retained integration code currently does three things on that same live
session:
C/O/OUsubject role;/oic/dbefore the association is persisted.
The certificate UUID and OCF device UUID are separate identities; the code
does not assume that they match. It also does not accept an arbitrary first
certificate. The proposed package API is an explicit first-use profile which
keeps all of the existing chain and role checks, exposes the verified
certificate UUID on the completed session, and retains no learned identity in
the reusable authentication provider. Normal reconnects continue to use
bound_device().2. Retire an HVR-only half-open peer
On both WD53 appliances, a failed initial handshake can stop after the DTLS
HelloVerifyRequest exchange. The appliance then retains the half-open peer on
that UDP tuple and ignores a clean retry long enough to make setup look
unrecoverable.
The retained integration handles only the narrowly proven transcript: a fixed
non-zero local UDP port, at least two ClientHello records, and inbound
handshake messages consisting only of HelloVerifyRequest. It sends one
epoch-zero fatal
handshake_failurealert for that half-open peer and returnscontrol to the caller, which owns the settle delay and any retry.
I propose keeping this opt-in and fail-closed:
local_port;HVR-only shape;
connect(); andretry is appropriate.
I am splitting these into two small PRs so the identity contract and cleanup
wire behavior can be reviewed independently. A final documentation/API
contract PR can then show the complete supported connection surface without
moving ownership policy into this package.