NPR Enhancement Proposals (NEP) » NEP-0002: Master Authentication and Optional Slave Authentication for NPR

Abstract

This document specifies a backward-compatible NPR extension that adds:

1. authenticated identification of the master station, and
2. optional or mandatory authentication of slaves connecting to that master.

The extension is intentionally limited to authentication and authorization. It does not provide confidentiality, and it does not require signatures on all traffic frames.

The extension is designed for amateur-radio use on constrained hardware. It prioritizes:

• compatibility with existing NPR framing,
• low implementation complexity,
• no dependence on real-time clocks,
• bounded on-air overhead,
• tolerance of hardware without secure non-volatile state.

Master authentication is always available when this extension is implemented. Slave authentication is controlled by master policy and MAY be disabled, optional, or required.

Motivation

In the baseline NPR design, a slave can attempt to connect to a master by sending a connection request in the discovery slot. The master replies with a connection ACK or NACK. The signaling channel uses TLV-encoded messages carried in signaling frames.

This baseline behavior provides no cryptographic proof of master identity and no cryptographic proof that a connecting slave is authorized to join. A receiver may therefore be unable to distinguish:

• a legitimate master from a spoofed or replayed advertisement,
• an authorized slave from an unauthorized one,
• a stale connection attempt from a fresh one.

At the same time, NPR is explicitly used in an amateur-radio environment where full link encryption is often undesirable or unnecessary, and where low-cost hardware, small memory budgets, and low data rates are important constraints.

This proposal improves authenticity and admission control while preserving NPR’s lightweight operational character.

Terminology

This document uses the following terms:

• master: the NPR station that allocates client IDs and TDMA slots.
• slave: a station attempting to connect to, or already connected to, a master.
• authentication: cryptographic proof of possession of a private key corresponding to a public key.
• authorization: the policy decision whether a peer public key is permitted.
• allowlist: a master-local mapping of permitted slave public keys.
• TOFU: trust on first use; a local slave policy outside the protocol.
• signaling frame: an NPR frame with signaling protocol ID and a TLV payload.

Goals

This proposal aims to:

• let a slave passively learn and verify master identity before transmitting,
• let a master require, accept, or ignore slave authentication,
• preserve compatibility with parsers that ignore unknown TLV elements,
• avoid requiring a real-time clock,
• avoid requiring a persistent boot counter,
• avoid signatures on every data frame,
• keep the authentication design simple by always carrying full public keys on air, avoiding separate key-identifier lookup mechanisms.

Non-Goals

This proposal does not aim to provide:

• confidentiality,
• traffic analysis resistance,
• perfect anti-replay for passive listeners,
• full integrity protection for all NPR traffic,
• perfect prevention of short-lived spoofing between periodic reauthentication events,
• mandatory TOFU behavior or mandatory slave key storage policy.

Design Overview

The extension adds three new signaling TLV elements:

1. MASTER_AUTH_BEACON A downlink broadcast TLV emitted by the master in signaling frames. It provides the master’s signed identity statement and a fresh challenge value.
2. CLIENT_AUTH An uplink TLV emitted by a slave together with a normal connection request. It proves possession of the slave private key and binds the request to a recent master beacon.
3. MASTER_AUTH_REPLY A downlink TLV emitted by the master together with a connection ACK or NACK. It proves liveness of the master by signing a nonce supplied by the slave.

This proposal does not modify the existing semantics of connection request, connection ACK, connection NACK, WHO, disconnect request, or disconnect ACK. Existing TLV elements remain valid and unchanged.

Cryptographic Primitives

This specification defines version 1 of the extension as follows:

• Public-key algorithm: Ed25519
• Fingerprint algorithm: BLAKE2b
• Signature size: 64 octets
• Public key size: 32 octets

The key_type field is included for future extensibility. For this version, the only defined value is:

• 0x01 = Ed25519

Implementations of this NEP version MUST support key_type = 0x01.

Master Policy Modes

A master implementing this NEP MUST support the following slave-authentication policy modes:

• OPEN: slave authentication is not used for admission control.
• OPTIONAL: authenticated slaves are verified if they provide CLIENT_AUTH; unauthenticated legacy slaves MAY still connect.
• REQUIRED: a slave MUST successfully authenticate or the master MUST deny the connection.

These policy modes concern slave authentication only.

Master authentication signaling is independent of whether slave authentication is open, optional, or required.

Wire Format

All new elements defined here are additional TLV entries inside the existing NPR signaling frame format. Signaling frames already carry chained TLV elements and terminate with END (0xFF, length 0).

Type numbers are TBD by registry allocation.

In this version of the protocol, full public keys are always carried in authentication TLVs. On-air key fingerprints are not defined as protocol fields.

MASTER_AUTH_BEACON TLV

• Direction: master to all slaves
• Context: signaling frame, broadcast downlink

Fields

• version : 1 octet Extension version. This document defines value 1.
• flags : 1 octet Bit field:
  • bit 0: SLAVE_AUTH_OPTIONAL
  • bit 1: SLAVE_AUTH_REQUIRED
  • bits 2-7: reserved, MUST be zero on transmission and ignored on reception unless defined later
• key_type : 1 octet Currently 0x01 for Ed25519.
• beacon_counter : 4 octets, unsigned Monotonic counter for master-authentication epochs within the current runtime instance.
• master_nonce : 8 octets Fresh challenge value chosen by the master.
• master_pubkey : 32 octets The raw octets of the master’s public key.
• signature : 64 octets Ed25519 signature over the transcript defined below.

Signature Transcript

The MASTER_AUTH_BEACON.signature field is computed over the following octet sequence:

1. ASCII domain separator: NPR-MASTER-AUTH-V1
2. network_id
3. version
4. flags
5. key_type
6. beacon_counter
7. master_nonce
8. master_pubkey
9. the raw octets of the master’s own WHO TLV from the same signaling frame

The master’s own WHO information is already carried in NPR signaling practice and is broadcast periodically, nominally every 2 seconds.

The WHO TLV included in the transcript MUST be the master’s self-description TLV from the same signaling frame that carries the MASTER_AUTH_BEACON.

Rationale

This transcript binds the beacon to:

• a specific NPR network,
• a specific current WHO advertisement,
• a specific current authentication epoch.

It also lets a slave verify the beacon from data already present in the current received signaling frame, without needing historical state beyond the configured network_id.

Notes on

A master MUST include master_pubkey in every beacon.

This choice intentionally increases beacon size in exchange for simpler implementation, easier passive key discovery, simpler TOFU workflows, and simpler operator approval flows.

Implementations MAY derive a fingerprint from master_pubkey for local display, logging, configuration, or user confirmation. Such fingerprints are not transmitted by this version of the protocol.

CLIENT_AUTH TLV

• Direction: slave to master
• Context: signaling frame, uplink; normally transmitted together with a standard connection request

Fields

• version : 1 octet Value 1.
• key_type : 1 octet Currently 0x01 for Ed25519.
• client_pubkey : 32 octets Is mandatory.
• beacon_counter_echo : 4 octets The beacon_counter from the most recently accepted master beacon.
• master_nonce_echo : 8 octets The master_nonce from the most recently accepted master beacon.
• client_nonce : 8 octets Fresh challenge value chosen by the slave.
• signature : 64 octets Ed25519 signature over the transcript defined below.

Signature Transcript

The CLIENT_AUTH.signature field is computed over the following octet sequence:

1. ASCII domain separator: NPR-CLIENT-AUTH-V1
2. network_id
3. version
4. key_type
5. client_pubkey
6. beacon_counter_echo
7. master_nonce_echo
8. client_nonce
9. the raw octets of the accompanying connection request TLV

The connection request remains the normal NPR connection request signaling element. This proposal does not replace it. Connection requests are already sent by an unconnected slave in the discovery slot using client ID 0x7E.

Authorization Decision

Upon receiving a valid CLIENT_AUTH, the master:

1. determines whether client_pubkey is authorized under local policy,
2. verifies the signature,
3. then decides whether to accept or reject the connection.

The allowlist format is implementation-specific and out of scope.

MASTER_AUTH_REPLY TLV

Direction: master to slave Context: signaling frame, downlink; transmitted together with connection ACK or connection NACK

Fields

• version : 1 octet Value 1.
• status : 1 octet Values:
  • 0x00 = success
  • 0x01 = unauthorized
  • 0x02 = bad signature
  • 0x03 = stale or unknown beacon
  • 0x04 = policy rejects unauthenticated connect
  • 0x05 = unsupported key type
  • 0x06-0xFF = reserved
• key_type : 1 octet Currently 0x01.
• client_nonce_echo : 8 octets The client_nonce from the triggering CLIENT_AUTH.
• signature : 64 octets Ed25519 signature by the master.

Signature Transcript

The MASTER_AUTH_REPLY.signature field is computed over the following octet sequence:

1. ASCII domain separator: NPR-MASTER-AUTH-REPLY-V1
2. network_id
3. version
4. status
5. key_type
6. client_nonce_echo
7. the raw octets of the accompanying connection ACK or connection NACK TLV

This signature provides an active proof of master liveness and prevents a slave from treating a replayed passive beacon as sufficient proof that the current responding master is genuine.

Timing Requirements

The master’s ordinary signaling behavior already includes periodic broadcast signaling. In common NPR practice, WHO is sent every 2 seconds.

This proposal intentionally does not hard-code beacon timing in absolute seconds alone. Implementations SHOULD express timing relative to the x8 multiframe duration of the current modulation/profile, since discovery opportunities for unconnected slaves are naturally aligned with the multiframe structure.

Required Timing Properties

A compliant implementation MUST satisfy all of the following:

1. MASTER_AUTH_BEACON transmissions MUST recur often enough that an unconnected slave has a practical chance to receive one and respond with a connection request before the beacon_counter and master_nonce change.
2. The beacon_counter and master_nonce MUST change less frequently than MASTER_AUTH_BEACON is transmitted.
3. The beacon_counter and master_nonce period MUST be long enough to accommodate:
   • reception of a beacon,
   • slave verification,
   • waiting until the next usable discovery slot,
   • transmission of the connection request and CLIENT_AUTH.
4. A slave MUST use the currently received beacon_counter and master_nonce. This specification intentionally does not define a multi-window replay acceptance rule.

Recommended Timing

As deployment guidance, implementations SHOULD satisfy:

• MASTER_AUTH_BEACON transmission interval: no more often than once every 1 x8 multiframe and no less often than once every 3 x8 multiframes.
• beacon_counter and master_nonce rotation interval: no more often than once every 3 x8 multiframes and no less often than once every 6 x8 multiframes.

An implementation MAY choose more conservative timings where appropriate, but SHOULD remain within these bounds unless there is a clear operational reason not to.

Nonce Generation

Master Nonce

master_nonce MUST be unpredictable to an external observer before transmission.

An implementation MAY generate it using:

• a good hardware random source,
• a cryptographic coprocessor,
• a software CSPRNG appropriately seeded,
• another implementation-specific method with equivalent unpredictability.

This specification does not require non-volatile storage and does not require any specific notion of boot identity or persistent counter state.

If a master cannot generate sufficiently unpredictable master_nonce values, the extension remains syntactically valid but provides weaker replay resistance. Implementations SHOULD document this limitation.

Slave Nonce

client_nonce MUST be fresh for each new CLIENT_AUTH transmission attempt and SHOULD be generated from a source of randomness of comparable quality.

Connection Procedure

Passive Master Authentication

Before transmitting, a slave MAY passively collect MASTER_AUTH_BEACON frames.

If the slave has a configured or trusted master public key, it SHOULD verify the beacon signature before attempting connection.

The slave MAY store or present master_pubkey according to local policy.

A slave MUST NOT treat a passive beacon alone as proof of current master liveness. Current liveness is established only by receiving a valid MASTER_AUTH_REPLY over the slave’s own client_nonce.

Initial Connect

A new slave connecting to a new master proceeds as follows:

1. The slave receives a signaling frame containing at least:
   • the master’s WHO TLV,
   • MASTER_AUTH_BEACON.
2. The slave verifies the master beacon if its local policy allows or requires doing so.
3. The slave transmits a standard NPR connection request in the discovery slot, together with CLIENT_AUTH.
4. The master processes the connection request normally and, if applicable, evaluates the CLIENT_AUTH.
5. The master returns the normal connection ACK or connection NACK, together with MASTER_AUTH_REPLY.
6. The slave verifies MASTER_AUTH_REPLY.
7. If both the NPR connection response and MASTER_AUTH_REPLY are acceptable under local policy, the connection proceeds.

Periodic Reauthentication

Connected clients already send periodic connection requests to maintain state, and masters already time out silent clients.

A slave implementing this NEP SHOULD attach CLIENT_AUTH to its periodic connection-maintenance request as well.

A master in OPTIONAL or REQUIRED mode MAY use this repeated CLIENT_AUTH to refresh authentication state.

This proposal reuses CLIENT_AUTH for both initial authentication and refresh. No separate refresh TLV is defined.

Behavior by Master Policy Mode

OPEN

In OPEN mode:

• the master MAY emit MASTER_AUTH_BEACON,
• the master MUST accept a legacy unauthenticated connection request if it would otherwise accept it,
• the master MAY verify CLIENT_AUTH when provided,
• a bad CLIENT_AUTH SHOULD result in connection denial only if local policy explicitly says so.

OPTIONAL

In OPTIONAL mode:

• the master SHOULD emit MASTER_AUTH_BEACON,
• the master MUST accept a legacy unauthenticated connection request if policy allows legacy clients,
• the master MUST verify CLIENT_AUTH when present,
• the master SHOULD return an authenticated failure reason when CLIENT_AUTH is present but invalid.

REQUIRED

In REQUIRED mode:

• the master SHOULD emit MASTER_AUTH_BEACON,
• the master MUST reject connection attempts that do not include valid CLIENT_AUTH,
• the master MUST reject connection attempts from unauthorized keys,
• the master SHOULD accompany a rejection with MASTER_AUTH_REPLY.status indicating the reason.

Connection NACK Reasons

This proposal does not redefine the existing NACK TLV payload. Existing NPR NACK reasons remain as defined by the base protocol.

Authentication-related details are carried in MASTER_AUTH_REPLY.status.

This avoids changing the wire format of the existing NACK element while still providing detailed diagnostics to new implementations.

Disconnect and Timeout Behavior

In baseline NPR behavior, a client periodically sends connection requests while connected, and both sides eventually return to reconnect behavior if expected maintenance signaling is not received.

This proposal does not require a new explicit server-driven disconnect mechanism for authentication failure.

If a master determines that a connected slave is no longer authenticated under local policy, the master MAY:

• stop considering that slave authenticated,
• stop allocating traffic opportunities to that slave,
• stop acknowledging that slave’s maintenance requests,
• optionally send a NACK plus MASTER_AUTH_REPLY on the next relevant signaling opportunity.

A slave will then revert to reconnect behavior according to existing NPR timeout logic.

Implementations SHOULD avoid immediate reuse of the same client_id for a newly connecting different slave until the previous state has clearly aged out.

Backward Compatibility

This proposal is designed to be backward compatible with existing NPR implementations that ignore unknown TLV elements as long as the signaling frame remains structurally valid.

New Master / Old Slave

• If slave-auth policy is OPEN or OPTIONAL, an old slave MAY connect using the legacy connection procedure.
• If slave-auth policy is REQUIRED, the master MUST reject the connection.
• The old slave will ignore the new authentication TLVs.

Old Master / New Slave

• A new slave MAY attempt to use this extension.
• If the old master ignores CLIENT_AUTH and does not provide MASTER_AUTH_BEACON or MASTER_AUTH_REPLY, the new slave MUST decide according to local policy whether legacy unauthenticated master operation is acceptable.
• A slave whose local policy requires verified master identity MUST refuse such a connection.

New Master / New Slave

• Full operation is available.
• The slave can verify passive master identity, provide client authentication, and verify active master liveness via MASTER_AUTH_REPLY.

Old Master / Old Slave

• Unchanged.

Unknown TLV Behavior

This proposal relies on the existing practical behavior that unknown TLV elements are ignored when the frame is otherwise structurally valid. A malformed TLV stream remains an error.

Therefore, implementations introducing these TLVs MUST ensure:

• correct TLV lengths,
• correct END TLV termination,
• no ambiguity in existing fields,
• no reordering assumptions that break existing parsers.

Rationale

Why separate TLVs instead of extending CONNECT_REQ and CONNECT_ACK?

Appending fields to existing known TLVs may work in tolerant parsers, but separate TLVs are more robust and more clearly aligned with TLV extensibility as a design principle.

This proposal therefore leaves existing connection TLVs semantically unchanged and carries authentication in parallel TLVs.

Why always carry the full public key?

This proposal requires the full public key to be present in both master and slave authentication TLVs.

Compared with compact key identifiers or fingerprints, this increases on-air size modestly but significantly simplifies implementation. Receivers do not need to maintain a separate identifier-to-key lookup path in order to verify signatures. It also simplifies passive key discovery, TOFU-style workflows, operator approval, and debugging.

Fingerprints remain useful for human-facing display and management, but they are treated as a local presentation detail rather than a wire-format dependency.

Why authenticate the master twice?

Because passive signed broadcast and active challenge-response solve different problems.

• MASTER_AUTH_BEACON lets a slave passively evaluate who claims to be the master.
• MASTER_AUTH_REPLY proves that the current responder holds the master private key and is not merely replaying an old beacon.

Why not sign every frame?

Signing every frame would significantly increase on-air cost and implementation complexity, especially on constrained hardware and low data rates. This proposal intentionally protects admission control and periodic reauthentication without making NPR traffic universally signed.

Why include key_type if only one type is defined?

To reserve protocol structure for future agility while keeping version 1 simple. The one-octet cost is modest.

Why no real-time clock?

This proposal is intended to work on hardware without RTC, without reliable wall-clock time, and without mandatory non-volatile counters. The timing model is therefore based on NPR multiframe-relative behavior rather than absolute time synchronization.

Security Considerations

What this proposal improves

This proposal materially improves NPR by adding:

• cryptographic proof of master identity,
• cryptographic proof of slave key possession,
• master-side authorization by public key,
• active master liveness confirmation through slave-supplied nonce signing,
• clearer operator-visible failure modes.

Replay

Passive replay of MASTER_AUTH_BEACON is not fully eliminated. A replayed beacon may still appear valid as a signed historical statement, especially because this proposal intentionally permits beacon and nonce rotation intervals long enough to accommodate slow modulation profiles and constrained hardware. This is mitigated, but not completely prevented, by requiring MASTER_AUTH_REPLY over a fresh slave nonce before treating master identity as live and current.

No confidentiality

This proposal provides no encryption. Public keys are visible on air when transmitted. This is deliberate and acceptable for the intended amateur-radio environment.

Key enumeration

Because master_pubkey and client_pubkey are always transmitted in authentication TLVs, passive observers can enumerate participating public keys. This is a privacy trade-off accepted by design.

Partial integrity only

Because data frames are not signed, an attacker may still attempt short-lived spoofing, interference, or slot misuse between periodic authenticated maintenance events. This proposal does not fully solve those problems.

Randomness quality

Poor random sources weaken replay resistance and liveness assurance. Implementations SHOULD use the best randomness source available, but this NEP does not mandate a specific hardware mechanism.

Malformed TLVs

A malformed authentication TLV can still cause whole-frame rejection in implementations that reject broken TLV streams. This proposal therefore requires conservative and well-tested serialization.

Implementation Notes

Master

A master implementation will typically need:

• one Ed25519 key pair,
• policy state for OPEN, OPTIONAL, or REQUIRED,
• an allowlist or equivalent authorization policy for slave public keys,
• periodic emission of MASTER_AUTH_BEACON,
• verification of CLIENT_AUTH,
• emission of MASTER_AUTH_REPLY.

Slave

A slave implementation will typically need:

• ability to parse and verify MASTER_AUTH_BEACON,
• optional local store of trusted or observed master public keys,
• one Ed25519 key pair for slave authentication,
• ability to emit CLIENT_AUTH,
• ability to verify MASTER_AUTH_REPLY,
• local policy deciding whether unauthenticated legacy masters are acceptable.

IANA-like Considerations

This NEP allocates the following NPR signalling message type codes:

• 0x08 = MASTER_AUTH_BEACON
• 0x09 = CLIENT_AUTH
• 0x0A = MASTER_AUTH_REPLY

The values were chosen to extend the existing connection-related signalling block immediately after 0x05 (Connection request), 0x06 (Connection ACK), and 0x07 (Connection NACK), and immediately before 0x0B (Disconnect request) and 0x0C (Disconnect ACK). This keeps signalling type numbering grouped by protocol function.

key_type registry

• 0x00 = Reserved
• 0x01 = Ed25519
• 0x02-0x7F = Unassigned
• 0x80-0xFF = Reserved for private or experimental use

MASTER_AUTH_BEACON.flags registry

Bit assignments:

• bit 0 = SLAVE_AUTH_SUPPORTED
• bit 1 = SLAVE_AUTH_REQUIRED
• bits 2-7 = Reserved

A sender MUST NOT set SLAVE_AUTH_REQUIRED unless SLAVE_AUTH_SUPPORTED is also set.

MASTER_AUTH_REPLY.status registry

• 0x00 = Success
• 0x01 = Unauthorized key
• 0x02 = Bad signature
• 0x03 = Stale or unknown beacon
• 0x04 = Missing client authentication
• 0x05 = Unsupported key type
• 0x06 = Malformed authentication TLV
• 0x07 = Policy rejects legacy unauthenticated connect
• 0x08-0x7F = Unassigned
• 0x80-0xFF = Reserved for private or experimental use

Open Questions

The following are intentionally left open for later implementation experience:

1. Whether operational experience will justify tightening or relaxing the recommended x8-multiframe-based timing bounds for specific modulation profiles.
2. Whether a project should define a canonical binary format for network_id inside signature transcripts if multiple host-side representations exist.
3. Whether future versions should define compact fingerprints on air as optional hints for operator UI and logs.
4. Whether a later NEP should define stronger refresh semantics for already-connected high-value links.

References

Normative References

• NEP-0001.
• NPR specification v2.0:
  • signaling frames and TLV chaining, connection request/ACK/NACK, and disconnect semantics.
    
  • WHO periodic signaling behavior.

Informative References

• RFC 2119, Key words for use in RFCs to Indicate Requirement Levels. ([rfc-editor.org][2])
• RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. ([rfc-editor.org][3])
• PEP 1, PEP Purpose and Guidelines. ([Python Enhancement Proposals (PEPs)][1])