[chrony-dev] [Git][chrony/chrony][master] 6 commits: nts: construct key exporter context

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


Title: GitLab

Miroslav Lichvar pushed to branch master at chrony / chrony

Commits:

  • 2adda9c1
    by Miroslav Lichvar at 2024-09-26T12:45:44+02:00
    nts: construct key exporter context
    
    When the NTS client and server negotiated use of AES-128-GCM-SIV keys,
    the keys exported from the TLS session and used for authentication and
    encryption of NTP messages do not comply to RFC8915. The exporter
    context value specified in the section 5.1 of RFC8915 function is
    incorrect. It is a hardcoded string which contains 15 (AES-SIV-CMAC-256)
    instead of 30 (AES-128-GCM-SIV). This causes chrony to not interoperate
    with NTS implementations that follow RFC8915 correctly. (At this time,
    there doesn't seem to be another implementation with AES-128-GCM-SIV
    support yet.)
    
    Replace the string with a proper construction of the exporter context
    from a specified AEAD ID and next protocol.
    
    Keep using the incorrect AEAD ID for AES-128-GCM-SIV to not break
    compatibility with existing chrony servers and clients. A new NTS-KE
    record will be added to negotiate the compliant exporter context.
    
    Reported-by: Martin Mayer <martin.mayer@xxxxxxxxxxxxxxxxxx>
    
  • 07078654
    by Miroslav Lichvar at 2024-09-26T16:04:01+02:00
    nts: negotiate compliant export of AES-128-GCM-SIV keys
    
    Add client and server support for a new NTS-KE record to negotiate use
    of the compliant key exporter context with the AES-128-GCM-SIV AEAD as
    specified here:
    
    https://chrony-project.org/doc/spec/nts-compliant-128gcm.html
    
  • 689605b6
    by Miroslav Lichvar at 2024-10-03T15:02:03+02:00
    nts: switch client to compliant key exporter on NTS NAK
    
    Implement a fallback for the NTS-NTP client to switch to the compliant
    AES-128-GCM-SIV exporter context when the server is using the compliant
    context, but does not support the new NTS-KE record negotiating its use,
    assuming it can respond with an NTS NAK to the request authenticated
    with the incorrect key.
    
    Export both sets of keys when processing the NTS-KE response. If an NTS
    NAK is the only valid response from the server after the last NTS-KE
    session, switch to the keys exported with the compliant context for the
    following requests instead of dropping all cookies and restarting
    NTS-KE. Don't switch back to the original keys if an NTS NAK is received
    again.
    
  • f5cd79d2
    by Miroslav Lichvar at 2024-10-03T15:02:16+02:00
    nts: check TLS session in NKSN_GetKeys()
    
    Make sure the TLS session is not NULL in NKSN_GetKeys() before trying to
    export the keys in case some future code tried to call the function
    outside of the NTS-KE message handler.
    
  • 79a790e6
    by Miroslav Lichvar at 2024-10-03T15:02:16+02:00
    test: improve nts_ke_client unit test
    
  • 42fbf416
    by Miroslav Lichvar at 2024-10-03T16:09:53+02:00
    nts: make server and client AEAD algorithms configurable
    
    Add ntsaeads directive to specify a list of AEAD algorithms enabled for
    NTS. The list is shared between the server and client. For the client it
    also specifies the order of priority. The default is "30 15", matching
    the previously hardcoded preference of AES-128-GCM-SIV (30) over
    AES-SIV-CMAC-256 (15).
    

16 changed files:



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/