First round of my stupid questions about NTS

[Richard Laager]

On 1/18/19 3:57 PM, Gary E. Miller via devel wrote:
> On Fri, 18 Jan 2019 13:15:49 -0800
> Hal Murray via devel <devel at ntpsec.org> wrote:
> 
>> Gary said:
>>>> S2C and C2S depend on the TLS session key.  
>>> Disagree.   
>>
>> It's in section 5.1 which refers to RFC 5705
>>   Keying Material Exporters for Transport Layer Security (TLS)
> 
> Thanks, that seems to prove my point.  The S2C and C2S are 'extracted'
> not 'dependent'.

RFC 5705 starts, "A number of protocols wish to leverage Transport Layer
Security (TLS) [RFC5246] or Datagram TLS (DTLS) [RFC4347] to perform key
 establishment but then use some of the keying material for their own
purposes."

Unless I'm misunderstanding, that is exactly what is going on here...
NTS-KE uses TLS. Then the TLS session is used to provide keys to NTS-KE
for ultimate use in NTP. So the keys that NTS-for-NTP calls C2S and S2C
are derived/extracted from the TLS session state as described in RFC
5705 section 4:

PRF(SecurityParameters.master_secret,
    label,
    SecurityParameters.client_random +
      SecurityParameters.server_random +
      context_value_length +
      context_value
   )[length]

Substituting in the values from NTS-for-NTP section 5.1, we get:

C2S (context ending with 0x00):

PRF(SecurityParameters.master_secret,
    "EXPORTER-network-time-security/1",
    SecurityParameters.client_random +
      SecurityParameters.server_random +
      0x05 +
      0x00 + 0x00 + 0x__ + 0x__ + 0x00
   )[length]

S2C (context ending with 0x01):

PRF(SecurityParameters.master_secret,
    "EXPORTER-network-time-security/1",
    SecurityParameters.client_random +
      SecurityParameters.server_random +
      0x05 +
      0x00 + 0x00 + 0x__ + 0x__ + 0x01
   )[length]

Where the two-octet 0x__ + 0x__ is "the Numeric Identifier of the
negotiated AEAD Algorithm in network byte order".

This clearly depends on the TLS master_secret, client_random, and
server_random.

Hal's original statement was, "You can't precompute cookies.  They
contain S2C and C2S which depend on the TLS sesson key."

While there is technically nothing called a TLS session key in the TLS
standard, the use of "session key" in this context is quite common.

Here is a good summary:
"In context of TLS, people usually use the term session keys for the
four keys derived from the Master Secret (client write MAC key, server
write MAC key, client write encryption key, and server write encryption
key)."

--
https://security.stackexchange.com/questions/75917/are-session-keys-just-the-symmetric-keys

I understand Hal's point to be: S2C and C2S depend on the TLS session's
master secret, etc., and thus require the TLS session to be fully
established. Therefore, you cannot compute cookies prior to a particular
TLS session being established.

This seems correct to me.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190118/9971e46a/attachment.bin>