From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Feb 17 02:34:11 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8131296DE for ; Fri, 17 Feb 2017 02:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZAj87KrA4Oh for ; Fri, 17 Feb 2017 02:34:09 -0800 (PST) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9726412989C for ; Fri, 17 Feb 2017 02:34:06 -0800 (PST) Received: from lists.ntp.org (lists.ntp.org [10.224.90.243]) by lists.ntp.org (Postfix) with ESMTP id 4BBD486DAB6 for ; Fri, 17 Feb 2017 10:34:06 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 14F1386D76A for ; Fri, 17 Feb 2017 10:31:05 +0000 (UTC) Received: from rrzmta2.uni-regensburg.de ([194.94.155.52]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1cefoU-000O8B-LZ for ntpwg@lists.ntp.org; Fri, 17 Feb 2017 10:31:05 +0000 Received: from rrzmta2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B45C37328C for ; Fri, 17 Feb 2017 11:30:52 +0100 (CET) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by rrzmta2.uni-regensburg.de (Postfix) with ESMTP id 8E16773171 for ; Fri, 17 Feb 2017 11:30:52 +0100 (CET) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Fri, 17 Feb 2017 11:30:52 +0100 Message-Id: <58A6D0D9020000A100024B83@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Fri, 17 Feb 2017 11:30:49 +0100 From: "Ulrich Windl" To: "ntpwg@lists.ntp.org" Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.52 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Authentication issues for control messages X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" Hello! I had written a tool (in Perl) to query ntpd via mode 6 control requests (and mode 3 client requests) when I decided to implement authentication (MAC). The first issue is the lack of proper specification of the MAC. I wanted to implement symmetric MD5 keys only, but even that showed to be poorly specified: >From the specification there is no limit on the key length. In NTPv3 the key type was DES (64 bits for secret and digest it seems), but with MD5 keys the length of the secret seems variable, while the digest is 16 octets. It seems the documentation for ntp.keys mixes key sizes and digest sizes, because it claims "The key is 1 to 16 printable characters" for MD5. Likewise, RFC5095 talks about "designate a secret 128-bit MD5 key". The algorithm however seems to handle any secret size (although practical reasons forbid huge sizes). Looking at the source of ntpd, it seems the key size is limited by the internal representation of the keychain. Anyway, my code tho check the MAC finally came out as this: sub check_MAC($$$) { my ($self, $MAC, $data) = @_; my $result = 0; my $keyid = $self->MAC_KeyID($MAC); my $key = $self->ID($keyid); if ($key && $key->Type() == AuthKey::KT_MD5) { my $keyval = $key->Value(); my $ctx = Digest::MD5->new; $ctx->add($keyval, $data); $result = $ctx->digest() eq MAC_Digest($MAC); } elsif ($keyid == 0 && length(MAC_Digest($MAC)) == 0) { # 'crypto-NAK' $result = 1; } else { # "Unknown MAC KeyID $keyid" unless zero } return $result; } And the code to create a MAC is this: sub MAC($$$) { my ($self, $keyid, $data) = @_; my $key = $self->ID($keyid); my $result = ''; if ($key && $key->Type() == AuthKey::KT_MD5) { my $keyval = $key->Value(); my $ctx = Digest::MD5->new; $ctx->add($keyval, $data); $result = pack('N', $key->ID()) . $ctx->digest(); } elsif ($key) { # 'Unsupported key type', $key->Type(), 'for ID', $keyid } else { # "Missing key for ID $keyid" } return $result; } What I tried next was to query ntpd 4.2.8p9 using request packets with a MAC. The result was from confusing to inconsistent (the documentation is _very_ vague on these issues). For example RFC5095 just says: " While the NTPv3 symmetric key authentication scheme described in this document has been carried over from NTPv3, the Autokey public key authentication scheme new to NTPv4 is described in [RFC5906]." My expectation was that authenticated requests were answered by authenticated responses, and (possibly) that non-authentic requests (unknown keyID od bad Digest) were ignored by ntpd. Obviously that is not the case: A mode=6 op=2 request (read variables) never had a MAC, independent of the request having an unknown key, an untriusted key or a trusted key in use. A mode=6 op=1 request (read status) however attached a crypto-NAK for an unknown key, for an untrusted key, and for a trusted key. I was surprised that it happened for a trusted key also (assuming that my code to create the MAC is OK). A mode=3 query returned the expected results: crypto-NAK for unkown keyID and untrusted key; a valid MAC for a trusted key, and no MAC for requests without a MAC. What I'd like to see for a future NTP version is these: Bring control packets in line with time queries, that is: Send authenticated responses to authenticated requests, and allow to discard non-authenticated requests. Whenever responding to unauthenticated requests, the response should add a crypto-NAK. This may requre the control messages to know of two types of keys instead of one type (similar to SNMP's read and write communities): A set of keys to trust for requesting information (read), and a set of keys to trust for changing the configuration (write). At the moment there is no guarantee that a response to a control packet is really from the server, because ntpd denies any request to authenticate responses, it seems. Comments and pointers to (non-contradicting) specifications welcome! Regards, Ulrich Windl _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Feb 22 01:27:01 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903A21296A4 for ; Wed, 22 Feb 2017 01:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6MHHbym2ZYn for ; Wed, 22 Feb 2017 01:27:00 -0800 (PST) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34512969C for ; Wed, 22 Feb 2017 01:27:00 -0800 (PST) Received: from lists.ntp.org (lists.ntp.org [10.224.90.243]) by lists.ntp.org (Postfix) with ESMTP id C19EA86DAAD for ; Wed, 22 Feb 2017 09:26:59 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id 96DFF86D77E for ; Wed, 22 Feb 2017 08:38:17 +0000 (UTC) Received: from mx0a-0016f401.pphosted.com ([67.231.148.174] helo=mx0b-0016f401.pphosted.com) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1cgSR4-0000uX-Gg; Wed, 22 Feb 2017 08:38:17 +0000 Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1M8Z1dU022605; Wed, 22 Feb 2017 00:38:03 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 28ppp1dw9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2017 00:38:02 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Feb 2017 10:37:59 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Wed, 22 Feb 2017 10:37:59 +0200 From: Tal Mizrahi To: "ntpwg@lists.ntp.org" , "Karen ODonoghue (odonoghue@isoc.org)" , "'dieter.sibold@ptb.de'" , "Harlan Stenn (stenn@nwtime.org)" , "Danny Mayer (mayer@ntp.org)" , Tal Mizrahi Thread-Topic: Comments about draft-stenn-ntp-extension-fields Thread-Index: AdKM5hSQyyJcUApyTZGfXjCcSDh00g== Date: Wed, 22 Feb 2017 08:37:58 +0000 Message-ID: <020c72ac4ac14b50af56c315a157b1e4@IL-EXCH01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-22_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702220086 X-SA-Exim-Connect-IP: 67.231.148.174 X-SA-Exim-Rcpt-To: mayer@ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: talmi@marvell.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Comments about draft-stenn-ntp-extension-fields X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2476075813369058232==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" --===============2476075813369058232== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_020c72ac4ac14b50af56c315a157b1e4ILEXCH01marvellcom_" --_000_020c72ac4ac14b50af56c315a157b1e4ILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, After having reviewed the draft, here is my take on it. I recommend to let the draft expire, and not to pursue it. The draft touches two main topics: 1. Redefining the format of the field: I believe it would be best to leave the as currently defined i= n RFC5905: a 16-bit IANA defined value. Specifically, in RFC5906 the field = is broken down into a few sub-fields that comply to the RFC5906-IANA-assign= ed-fields. We asked the working group whether there is interest to change the semantic= s of the , and there were zero responses. This strengthens the motivation to not change anything. 2. Updating the extension field detection logic: The way I see it the draft suggests three main changes compared to the curr= ent logic: (1) Avoid the at-least-28-octet logic that was defined in RFC590= 6 and RFC7822, (2) Detect the Last-EF, and (3) Detect MAC-EF. I believe (1) would cause ambiguous parsing logic. I believe (2) and (3) sh= ould be defined in their own drafts if the WG is interested to pursue them. The bottom line is that I would suggest to let this draft expire and not to= pursue it. The MAC-EF and Last-EF can be pursued in different drafts if the WG support= s them. I appreciate the work Harlan has done in the last few months over this draf= t and others. BTW, I really think it would be helpful to discuss the extens= ion-field-parsing pseudo-code with the WG, and make sure it is consistent w= ith RFC5905, RFC5906, RFC7822. Cheers, Tal. --_000_020c72ac4ac14b50af56c315a157b1e4ILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

After having reviewed the draft, here is my take on = it.

 

I recommend to let the draft expire, and not to purs= ue it.

 

The draft touches two main topics:

1.     &= nbsp; Redefining the format of t= he <Field Type> field:
I believe it would be best to leave the <Field Type> as currently def= ined in RFC5905: a 16-bit IANA defined value. Specifically, in RFC5906 the = field is broken down into a few sub-fields that comply to the RFC5906-IANA-= assigned-fields.
We asked the working group whether there is interest to change the semantic= s of the <Field Type>, and there were zero responses.
This strengthens the motivation to not change anything.

2.       Updating the extension fie= ld detection logic:
The way I see it the draft suggests three main changes compared to the curr= ent logic: (1) Avoid the at-least-28-octet logic that was defined in RFC590= 6 and RFC7822, (2) Detect the Last-EF, and (3) Detect MAC-EF.
I believe (1) would cause ambiguous parsing logic. I believe (2) and (3) sh= ould be defined in their own drafts if the WG is interested to pursue them.=

The bottom line is that I would suggest to let this = draft expire and not to pursue it.

The MAC-EF and Last-EF can be pursued in different d= rafts if the WG supports them.

 

I appreciate the work Harlan has done in the last fe= w months over this draft and others. BTW, I really think it would be helpfu= l to discuss the extension-field-parsing pseudo-code with the WG, and make = sure it is consistent with RFC5905, RFC5906, RFC7822.

 

Cheers,

Tal.

 

--_000_020c72ac4ac14b50af56c315a157b1e4ILEXCH01marvellcom_-- --===============2476075813369058232== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2476075813369058232==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Feb 22 01:27:51 2017 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328FD1296A4 for ; Wed, 22 Feb 2017 01:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 376229mlBvva for ; Wed, 22 Feb 2017 01:27:49 -0800 (PST) Received: from lists.ntp.org (psp3.ntp.org [185.140.48.241]) by ietfa.amsl.com (Postfix) with ESMTP id B73E912969C for ; Wed, 22 Feb 2017 01:27:49 -0800 (PST) Received: from lists.ntp.org (lists.ntp.org [10.224.90.243]) by lists.ntp.org (Postfix) with ESMTP id 7686386DB8F for ; Wed, 22 Feb 2017 09:27:49 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (fortinet.ntp.org [10.224.90.254]) by lists.ntp.org (Postfix) with ESMTP id B19F386D77E for ; Wed, 22 Feb 2017 08:49:03 +0000 (UTC) Received: from chessie.everett.org ([66.220.13.234]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1cgSbW-0000zW-HK for ntpwg@lists.ntp.org; Wed, 22 Feb 2017 08:49:03 +0000 Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id 80444B813 for ; Wed, 22 Feb 2017 08:48:53 +0000 (UTC) Received: from hms-mbp11.pfcs.com (96-41-177-107.dhcp.mdfd.or.charter.com [96.41.177.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 327E1B81C; Wed, 22 Feb 2017 08:48:52 +0000 (UTC) To: Tal Mizrahi , "ntpwg@lists.ntp.org" , "Karen ODonoghue (odonoghue@isoc.org)" , "'dieter.sibold@ptb.de'" , "Danny Mayer (mayer@ntp.org)" References: <020c72ac4ac14b50af56c315a157b1e4@IL-EXCH01.marvell.com> From: Harlan Stenn Message-ID: <6e22b4a7-62ef-c538-f943-0b5d399e48bb@nwtime.org> Date: Wed, 22 Feb 2017 00:48:51 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <020c72ac4ac14b50af56c315a157b1e4@IL-EXCH01.marvell.com> X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Feb 22 08:48:53 2017 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 6384,58ad5075107502097020287 X-SA-Exim-Connect-IP: 66.220.13.234 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: stenn@nwtime.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] Comments about draft-stenn-ntp-extension-fields X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: "ntpwg" And as folks might expect, I disagree. But I'm open to suggestions on how to proceed. It feels like I'm repeating myself when I either re-explain what's going on, or when I refute the points Tal is making again. I'll have code that implements what I've proposed soon. H On 2/22/17 12:37 AM, Tal Mizrahi wrote: > Hi, > > After having reviewed the draft, here is my take on it. > > I recommend to let the draft expire, and not to pursue it. > > The draft touches two main topics: > > 1. Redefining the format of the field: > I believe it would be best to leave the as currently defined in RFC5905: a 16-bit IANA defined value. Specifically, in RFC5906 the field is broken down into a few sub-fields that comply to the RFC5906-IANA-assigned-fields. > We asked the working group whether there is interest to change the semantics of the , and there were zero responses. > This strengthens the motivation to not change anything. > > 2. Updating the extension field detection logic: > The way I see it the draft suggests three main changes compared to the current logic: (1) Avoid the at-least-28-octet logic that was defined in RFC5906 and RFC7822, (2) Detect the Last-EF, and (3) Detect MAC-EF. > I believe (1) would cause ambiguous parsing logic. I believe (2) and (3) should be defined in their own drafts if the WG is interested to pursue them. > The bottom line is that I would suggest to let this draft expire and not to pursue it. > The MAC-EF and Last-EF can be pursued in different drafts if the WG supports them. > > I appreciate the work Harlan has done in the last few months over this draft and others. BTW, I really think it would be helpful to discuss the extension-field-parsing pseudo-code with the WG, and make sure it is consistent with RFC5905, RFC5906, RFC7822. > > Cheers, > Tal. > > -- Harlan Stenn http://networktimefoundation.org - be a member! _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg