Re: [TICTOC] [ntpwg] security ID submitted for review

[Greg Dowd <[e-mail]>]

I agree.  After the last thread about MAC recognition and extensions, I took a look back through the source of various versions and saw that the length check is being worked to keep up with digest mechanisms and is about to be capped by the extension draft minimum at 28.  I even went as far as looking up the ASN.1 encoding of hash OID and blob and it is reasonably efficient, adding less than a dozen bytes for mac'd frames in addition to the hmac IIRC.  If we do this, we need to consider as well the "keepouts" presented by Autokey's current implementation.  If the next autokey rev is not backwards compatible, it would be nice to update the autokey packets to use a TLV structure more amenable to sharing the association.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Danny Mayer
Sent: Sunday, November 10, 2013 12:15 PM
To: David L. Mills; Kurt Roeckx
Cc: NTP Working Group; [e-mail]
Subject: Re: [TICTOC] [ntpwg] security ID submitted for review

Dave,

I'm of the opinion that we should retire the MAC altogether and create a
MAC extension field instead. A lot of logic has been going into working
out whether or not we have an extension field or the MAC. The MAC
extension field could be REQUIRED to be the last extension field. That
way you know the length of each extension field and you could put
additional information in the MAC extension field indicating the type of
computation needed for the MAC. This makes a MAC easily extensible.

I'm not convinced that a server needs to authenticate a client except in
the context of an autokey dance. Then you only need to recognized the
key type presented and process according to that key type. I don't think
it's practical for the server to maintain state unless in the context of
an association. Drive-by NTP packets just are not worth the effort involved.

Danny

On 8/6/2013 9:01 PM, David L. Mills wrote:
> The more I think of it, the better I like a design where the existing
> MAC is replaced by a single extension field computed as the signature of
> the header.  I previously suggested this for broadcast mode, but I think
> this could be useful in other modes as well.  It would be hightly
> interesting to determine the overhead for such a signature using modern
> processors.  An experiment could be designed for the current NTP
> implementation.  It would consist of an adaptor routine that matches an
> OpenSSL signature routine to the authencrypt/authdecrypt interface
> routine.  I would do this myself, but with my current vision condition,
> it would not be practical.  For someone with knowledge of the NTP
> programming style, this would be an interesting weekend project.
> 
> In theis proposed design a busy server could be presented with thousands
> of signed client requests, each requiring  a signed server response. 
> However, the server might ignore the client request signature on the
> expectation that the  server response could be reliably determined. 
> Actually, the NTP on-wire protocol is very good for this.  As an aside,
> the protocol analysis and simulation described in the white paper at the
> NTP project page could be done for PTP as well.
> 
> Dave
> 
> Kurt Roeckx wrote:
>> On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote:
>>   
>>> Guys,
>>>
>>> Here are some general comments on the ID.  I apologize if they are a
>>> little rough as I have to dictate this message instead of my usual
>>> polished wordsmithing.
>>>
>>> format.
>>> The ID does not specify an extension field format.
>>>     
>>
>> The draft only seems to specify the the general idea of how it
>> should work and doesn't seem to go into detail how this should
>> work at the protocol level.  I assume he first wants to know if
>> the solution is something that can work and that others see
>> as a good solution before he works out the details.
>>
>>   
>>> In particular, the private key for the message
>>> authentication code (MAC) , if used, must be known beforehand.  This
>>> is where the "cookie snatcher" issue comes up as described in
>>> previous messages.  In particular, an important constraint for
>>> normal operation is that extension fields are not used unless
>>> required for cookie determination.
>>>     
>>
>> I'm not sure I understand your remark.  As far as I know the
>> "cookie snatcher" you talk about is the normal "man in the middle"
>> attack.  As I understand we would change the verification by
>> replacing it by the normal X.509 verification as done for instance
>> SSL/TLS.
>>
>> I assume you meant public key and note private key.
>>
>>   
>>> Glaring vulnerability exists when using extension fields, as the key
>>> value is public and must be known in advance.  This invites a
>>> cut-and-paste attack, as well as header changes, even if
>>> subsequently detected by the on-wire protocol.
>>>     
>>
>> I've seen this cut-and-paste attack mentioned before, but I've
>> never really understood it.  As I understand things, the MAC
>> is generated over the NTP + extensions.  I don't see how you
>> can take the extension from 1 packet into an other and still
>> have a valid MAC.  Or are you saying that you do something
>> with a packet even when it doesn't have a valid MAC?
>>
>>   
>>> certificate.
>>> Both RFC 5906 and the ID require the server certificate.  The server
>>> certificate can be conveyed, either off-line, or directly or
>>> indirectly via a certificate trail as described in RFC 5906 or the
>>> ID.  If obtained via the trail, there is a hazzard due to a
>>> middle-man attack and masquerade.
>>>     
>>
>> I really don't understand how such a man in the middle attack
>> can work.  Either the certificate + the chain validate, or they
>> don't.  It is of course important to you check that the CommonName
>> in the certificate matches the server you're trying to reach,
>> and that the root CA is in your list of trusted CAs.  But there
>> really isn't anything new or hard about this.
>>
>>   
>>> In broadcast mode, the protocols described in RFC 5906 and the ID
>>> are messy and with several possible vulnerabilities.  Here is a
>>> suggestion that might be useful.  Define a new broadcast packet
>>> format as the NTP header followed by one extension field
>>> representing the MAC.  The extension field represents the signature
>>> of the header computed using the private key of the server and can
>>> be verified by the client using the public key in the server
>>> certificate.  Originally, this was considered an unacceptable
>>> dilution of accuracy due to the variability of the signature
>>> computing time and the length of the signature.  However, at least
>>> in modern NTP, the interleaved broadcast mode can be used to correct
>>> for this overhead.  This assumes that the overhead for either the
>>> server or client is reduced using fast modern processors.
>>>     
>>
>> I think that in all cases where it's no problem to keep track of
>> all clients you should use the interleaved mode, and we can use
>> something like the Diffie-Hellman key agreement for those.
>>
>> But there clearly is also a need for servers that can't keep
>> the state of each client, and we need something else for that.
>> So maybe we need to define 2 ways of working.
>>
>>
>>
>> Kurt
>>
>>   
> 
> 
> 
> _______________________________________________
> ntpwg mailing list
> [e-mail]
> http://lists.ntp.org/listinfo/ntpwg
> 

_______________________________________________
TICTOC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tictoc