Subject: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

From: Tal Mizrahi <[email-masked]>
Date: Wed, 23 Apr 2014 15:39:53 +0300

Hi,

I have posted an updated draft.
http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-07

The most notable changes in this draft:

1.       I updated the draft to address comments from Shawn, the appointed secdir reviewer:
http://www.ietf.org/mail-archive/web/secdir/current/msg04315.html

2.       I updated the draft to address comments from Russell Smiley:
http://www.ietf.org/mail-archive/web/tictoc/current/msg01387.html
This includes:
- In section 5.1.3 and 5.1.4 we decoupled the authentication and authorization requirements. The authentication requirement level was changed to 'MUST' following the good observation made by Russell: "Absence of authentication of slaves may enable MITM attacks delaying delay_req packets and thereby distorting the delay_req packet arrival times and subsequent departure of delay_resp. The resulting asymmetry could distort the subsequent slave clock offset calculations."
- The authorization requirement remains 'MAY' for sections 5.1.3 and 5.1.4.

3.       The requirement level of section 5.8 was changed to 'MUST'. The background is the insight that MITM attacks (sections 3.2.5, 3.2.6) have the same impact and level of difficulty to implement as manipulation attacks (section 3.2.1). Hence, a similar requirement level is called for in the two cases.
Section 5.8 also clarifies that: "While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism."

4.       Section 5.2: merged the two sub-requirements to a single requirement for integrity protection. The previous phrasing called for hop-by-hop integrity protection as a MUST and end-to-end as a SHOULD, but some of the feedback we received was that in some scenarios or network topologies an end-to-end may provide a higher level of security. The current phrasing just presents the tradeoff between peer-to-peer and end-to-end.

Please let me know if there are any comments.

Thanks,
Tal.

---

From: [email-masked]
Date: Thu, 24 Apr 2014 18:23:28 +0200

Hello Tal,

I have one comment regarding Sec. 5.1.3.

This section requires that the master MUST authenticate each client. I 
think that this requirement should be a MAY! In the case of a public time 
service there is no need for the master to authenticate its slaves. The 
spoofing attack described in the second example of 3.2.2 can be mitigated 
by other means such as the introduction of a nonce in a time request or 
delay_req message. 

I agree that in the case of authorization of the slave authentication is 
also necessary. 

Greetings
Dieter 

----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100 
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: [email-masked]

Von:    Tal Mizrahi <[email-masked]>
An:     "[email-masked]" <[email-masked]>, "Yaakov Stein 
([email-masked])" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Kopie:  "Shawn M Emery \([email-masked]\)" 
<[email-masked]>
Datum:  23.04.2014 14:40
Betreff:        [TICTOC] Updated 
draft-ietf-tictoc-security-requirements-07
Gesendet von:   "TICTOC" <[email-masked]>

Hi,

The most notable changes in this draft:
1.       I updated the draft to address comments from Shawn, the appointed 
secdir reviewer:
http://www.ietf.org/mail-archive/web/secdir/current/msg04315.html
2.       I updated the draft to address comments from Russell Smiley: 
http://www.ietf.org/mail-archive/web/tictoc/current/msg01387.html
This includes:
- In section 5.1.3 and 5.1.4 we decoupled the authentication and 
authorization requirements. The authentication requirement level was 
changed to ‘MUST’ following the good observation made by Russell: “Absence 
of authentication of slaves may enable MITM attacks delaying delay_req 
packets and thereby distorting the delay_req packet arrival times and 
subsequent departure of delay_resp. The resulting asymmetry could distort 
the subsequent slave clock offset calculations.”
- The authorization requirement remains ‘MAY’ for sections 5.1.3 and 
5.1.4.
3.       The requirement level of section 5.8 was changed to ‘MUST’. The 
background is the insight that MITM attacks (sections 3.2.5, 3.2.6) have 
the same impact and level of difficulty to implement as manipulation 
attacks (section 3.2.1). Hence, a similar requirement level is called for 
in the two cases.
Section 5.8 also clarifies that: “While the security mechanism should 
support the ability to detect delay attacks, it is noted that in some 
networks it is not possible to provide the redundancy needed for such a 
detection mechanism.”
4.       Section 5.2: merged the two sub-requirements to a single 
requirement for integrity protection. The previous phrasing called for 
hop-by-hop integrity protection as a MUST and end-to-end as a SHOULD, but 
some of the feedback we received was that in some scenarios or network 
topologies an end-to-end may provide a higher level of security. The 
current phrasing just presents the tradeoff between peer-to-peer and 
end-to-end.

Thanks,
Tal.
 _______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 29 Apr 2014 08:04:01 +0300

Hi,

Dieter, thanks for the comments.
After some further offline discussion with Dieter, I understand the concern: in section 5.1.3 WRT authentication we actually implied two different requirements: (i) master authenticates the identity of the slave, and (ii) slave spoofing prevention.  As Dieter explains, (ii) can be satisfied even when (i) is not satisfied.

My suggestion is as follows:
Add a new subsection, “5.x Spoofing Prevention”, that requires a mechanism that prevents (i) master (server) spoofing. (ii) slave (client) spoofing, and (iii) TC spoofing (in PTP).
This new section will be a MUST.
We can then change 5.1.3 and 5.1.4 back to MAY.

Please let me know if there are further comments.

Thanks,
Tal.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 7:23 PM
To: Tal Mizrahi
Cc: [email-masked]
Subject: Re: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Hello Tal,

This section requires that the master MUST authenticate each client. I think that this requirement should be a MAY! In the case of a public time service there is no need for the master to authenticate its slaves. The spoofing attack described in the second example of 3.2.2 can be mitigated by other means such as the introduction of a nonce in a time request or delay_req message.

I agree that in the case of authorization of the slave authentication is also necessary.

Greetings
Dieter

E-Mail: [email-masked]<mailto:[email-masked]>

Von:        Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
An:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Yaakov Stein ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Kopie:        "Shawn M Emery \([email-masked]\<mailto:[email-masked]\>)" <[email-masked]<mailto:[email-masked]>>
Datum:        23.04.2014 14:40
Betreff:        [TICTOC] Updated draft-ietf-tictoc-security-requirements-07
Gesendet von:        "TICTOC" <[email-masked]<mailto:[email-masked]>>
________________________________

Hi,

The most notable changes in this draft:
1.       I updated the draft to address comments from Shawn, the appointed secdir reviewer:
http://www.ietf.org/mail-archive/web/secdir/current/msg04315.html
2.       I updated the draft to address comments from Russell Smiley:
http://www.ietf.org/mail-archive/web/tictoc/current/msg01387.html
This includes:
- In section 5.1.3 and 5.1.4 we decoupled the authentication and authorization requirements. The authentication requirement level was changed to ‘MUST’ following the good observation made by Russell: “Absence of authentication of slaves may enable MITM attacks delaying delay_req packets and thereby distorting the delay_req packet arrival times and subsequent departure of delay_resp. The resulting asymmetry could distort the subsequent slave clock offset calculations.”
- The authorization requirement remains ‘MAY’ for sections 5.1.3 and 5.1.4.
3.       The requirement level of section 5.8 was changed to ‘MUST’. The background is the insight that MITM attacks (sections 3.2.5, 3.2.6) have the same impact and level of difficulty to implement as manipulation attacks (section 3.2.1). Hence, a similar requirement level is called for in the two cases.
Section 5.8 also clarifies that: “While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism.”
4.       Section 5.2: merged the two sub-requirements to a single requirement for integrity protection. The previous phrasing called for hop-by-hop integrity protection as a MUST and end-to-end as a SHOULD, but some of the feedback we received was that in some scenarios or network topologies an end-to-end may provide a higher level of security. The current phrasing just presents the tradeoff between peer-to-peer and end-to-end.

Thanks,
Tal.
 _______________________________________________
TICTOC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Smiley, Russell" <[email-masked]>
Date: Tue, 29 Apr 2014 13:46:46 +0000

Tal,

Let me restate your separation of the requirements in the hope that I have understood correctly:

1.       Master authenticates slaves as a necessary component of authorizing slaves for access to the master services.

2.       Master authenticates slaves in order to uniquely identify slaves to prevent spoofing attacks.

If I understand correctly you want to make requirement (1) a MAY and (2) a MUST, with the understanding that the implementation of the authentication mechanism in (1) and (2) may be different.

I believe that Dieter suggests that a nonce would be adequate to satisfy (2). I am not confident of this assertion; a nonce is normally used to prevent a replay attack, so unless there is something about the implementation of a nonce that I have misunderstood I do not see how a nonce could prevent spoofing/MITM. Perhaps further explanation would be helpful?

In the case of a public master that Dieter is concerned about, I believe the authentication of slaves in (2) to prevent spoofing can be satisfied using a key exchange system such as in TLS; the keys are generated and exchanged per session within the context of a secure handshaking mechanism. Thus there is no/minimal prior knowledge needed to establish secure communications between master and slave.

Russell.

From: TICTOC [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Tuesday, April 29, 2014 1:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Hi,

Thanks,
Tal.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 7:23 PM
To: Tal Mizrahi
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Hello Tal,

Greetings
Dieter

Hi,

Thanks,
Tal.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 29 Apr 2014 16:55:37 +0300

Hi Russell,

Please see inline, marked [TM].

Thanks,
Tal.

From: Smiley, Russell [mailto:[email-masked]]
Sent: Tuesday, April 29, 2014 4:47 PM
To: Tal Mizrahi; [email-masked]
Cc: [email-masked]
Subject: RE: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Tal,

[TM] Yes

2.       Master authenticates slaves in order to uniquely identify slaves to prevent spoofing attacks.
[TM] Not exactly. The general way to phrase this is spoofing prevention. Dieter argued (and I agree) that slave spoofing can be prevented even if the master does not authenticate the identity of the slave.

[TM] Right.

I believe that Dieter suggests that a nonce would be adequate to satisfy (2). I am not confident of this assertion; a nonce is normally used to prevent a replay attack, so unless there is something about the implementation of a nonce that I have misunderstood I do not see how a nonce could prevent spoofing/MITM. Perhaps further explanation would be helpful?
[TM] I will try to phrase Dieter’s claim the way I understand it (Dieter – correct me if I am wrong). The slave can send Delay_Req packets with *something* (a nonce or something else) that is protected by a MAC with a key that only the slave has access to, and thus no other node can forge this MAC. The Delay_Resp message then includes the same *something* with the same MAC, allowing the slave to verify that the Delay_Resp corresponds to an authentic Delay_Req. As Dieter suggests, this prevents spoofing, and the master does not have to verify the master’s identity.

Russell.

Hi,

Thanks,
Tal.

Hello Tal,

Greetings
Dieter

Hi,

Thanks,
Tal.

---

From: "Smiley, Russell" <[email-masked]>
Date: Tue, 29 Apr 2014 15:06:40 +0000

Ok. To prevent spoofing of the downlink channel, presumably in Delay_Resp the master also includes its own MAC *m-something* as well as returning the slaves *s-something* ?

I agree with your separation of the two requirements.

From: Tal Mizrahi [mailto:[email-masked]]
Sent: Tuesday, April 29, 2014 9:56 AM
To: Smiley, Russell; [email-masked]
Cc: [email-masked]
Subject: RE: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Hi Russell,

Thanks,
Tal.

To: Tal Mizrahi; [email-masked]<mailto:[email-masked]>

Tal,

Russell.

To: [email-masked]<mailto:[email-masked]>

Hi,

Thanks,
Tal.

Hello Tal,

Greetings
Dieter

Hi,

Thanks,
Tal.