Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C389128DE5 for ; Fri, 9 Jun 2017 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1Jt_QieNL3mp for ; Fri, 9 Jun 2017 09:23:59 -0700 (PDT) Received: from smtp-6-48.vip.sina.com.cn (r3-62.sinamail.sina.com.cn [202.108.3.62]) by ietfa.amsl.com (Postfix) with SMTP id C5A0C124234 for ; Fri, 9 Jun 2017 09:23:57 -0700 (PDT) Received: from unknown (HELO WeiGengyuPC)([114.246.137.206]) by vip.sina.com with ESMTP 10 Jun 2017 00:23:49 +0800 (CST) X-Sender: weigengyu@vip.sina.com X-Auth-ID: weigengyu@vip.sina.com X-SMAIL-MID: 54642567436 Message-ID: From: "weigengyu" To: "Simon Bernard" , "Carsten Bormann" , "Kraus Achim \(INST/ECS4\)" Cc: References: <003501d2cd32$c4417a10$4cc46e30$@augustcellars.com> <005e01d2cd8f$ae548dc0$0afda940$@augustcellars.com> <014601d2daf1$8f1865c0$ad493140$@augustcellars.com> <849AEC05-87E3-48A7-B5C6-E6B6C8DC98D5@tzi.org> <015501d2dafe$dc53e640$94fbb2c0$@augustcellars.com> <0EE7D28C4BD94A4BB8ACA70FF0182BFC@WeiGengyuPC> <000001d2db51$a7d31c30$f7795490$@augustcellars.com> <000301d2db56$24df9ab0$6e9ed010$@augustcellars.com> <35046B0695F64F97ABE9E1965062E7FC@WeiGengyuPC> <83c2fca38c534509aa77241aa3105aad@FE-MBX1027.de.bosch.com> <4FC55496-308A-4FCA-8003-6E0B4BB92015@tzi.org> <88a7de1d-f9fe-3743-a58c-5cdd5ad7b82a@simonbernard.eu> In-Reply-To: <88a7de1d-f9fe-3743-a58c-5cdd5ad7b82a@simonbernard.eu> Date: Sat, 10 Jun 2017 00:23:49 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01D2E17F.D4FB9780" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [core] DTLS and Epochs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:24:04 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0105_01D2E17F.D4FB9780 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, In DTLS there is a formal to calculate a cookie:=20 Cookie =3D HMAC(Secret, Client-IP, Client-Parameters) Cookie is related to the Client-IP address and used during DTLS = handshakes.=20 If the IP address is changed just during handshanke stage, the handshake = will not continue. =20 Then it must start a new DTLS shandshake with the new IP address. If the IP address is changed during DTLS record delivery after a = successfule handshake,=20 the DTLS record carried in a new IP address would be treated to belong = to a different DTLS association.=20 In a receiving side with an unchanged IP address, the DTLS record would = be regarded as an invalide one to be discarded according to RFC6347.=20 So, for CoAP Observe if the IP address is changed, a new DTLS = association must be establishied.=20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Simon Bernard=20 Sent: Friday, June 09, 2017 6:35 PM To: Carsten Bormann ; Kraus Achim (INST/ECS4)=20 Cc: core@ietf.org=20 Subject: Re: [core] DTLS and Epochs Hi, We faced this issue when we tried to make observe work behind NAT in a = LWM2M context. My understanding is "same epoch" means implicitly "same DTLS = connection too" which is a real issue in dynamic IP address environment = (as DTLS connection is identified by IP address). "same epoch" means "no = TLS renegociation". IMHO, "same epoch/connection" should be replaced by "same identity" = (PSK identity for PSK, public key for RPK, CN for certificate) for = authenticated peer or "same session" for non-authenticated. In case you = want to allow TLS renegotiation you should add "same cipher" too. But = TLS renegotiation seems to be not advisable for DTLS 1.2 : = https://tools.ietf.org/html/rfc7925#section-17 and removed to DTLS 1.3 = last time I looked at it. I initially think about that for observe request, but maybe it can be = generalized to all request/response correlation. Here some discussion about this idea : - https://www.ietf.org/mail-archive/web/core/current/msg08019.html - https://www.ietf.org/mail-archive/web/core/current/msg08004.html Simon Le 08/06/2017 =C3=A0 11:08, Carsten Bormann a =C3=A9crit : On Jun 8, 2017, at 10:17, Kraus Achim (INST/ECS4) = mailto:Achim.Kraus@bosch-si.com wrote: It's still unclear to me, if this should be considered to be the "same = epoch" in the meaning of RFC7252. =20 I pointed to that last summer = (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), but = I could get clarification on that. I think that we can agree that the current definition is =E2=80=94 not fully clear =E2=80=94 unrealistic in certain implementation environments (so it may = not actually be implemented) =E2=80=94 unnecessarily restrictive. Now the next question is what definition would =E2=80=94 make sense from an implementers=E2=80=99 point of view =E2=80=94 not be unnecessarily restrictive =E2=80=94 retain the desirable security properties of the current = restrictive definition - be clear - maybe also make sense for DTLS 1.3 (which isn=E2=80=99t fully baked = yet). (And then we have to figure out the process for fixing it =E2=80=94 that = is not too hard once we know the extent of the change that needs to me = made. E.g., an RFC updating RFC 7252.) Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0105_01D2E17F.D4FB9780 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi all,
 
In DTLS there is a formal to calculate a cookie:
      Cookie =3D HMAC(Secret, Client-IP,=20 Client-Parameters)
Cookie is related to the Client-IP address and used during DTLS = handshakes.=20
 
If the IP address is changed just during handshanke stage, the = handshake=20 will not continue. 
Then it must start a new DTLS shandshake with the new IP = address.
 
If the IP address is changed during DTLS record delivery after a=20 successfule handshake,
the DTLS record carried in a new IP address would be treated to = belong to a=20 different DTLS association.
In a receiving side with an unchanged IP address, the DTLS record = would be=20 regarded as an invalide one to be discarded according to RFC6347.
 
So, for CoAP Observe if the IP address is changed, a new DTLS = association=20 must be establishied.
 
 
Regards,
 
Gengyu WEI
Network Technology Center
School of Computer =
Beijing=20 University of Posts and Telecommunications
 
Sent: Friday, June 09, 2017 6:35 PM
Subject: Re: [core] DTLS and Epochs
 

Hi,

  We faced this issue when we tried to make observe work behind = NAT in a=20 LWM2M context.

  My understanding is  "same epoch" means implicitly "same = DTLS=20 connection too" which is a real issue in dynamic IP address environment = (as DTLS=20 connection is identified by IP address). "same epoch" means "no TLS=20 renegociation".

  IMHO, "same epoch/connection" should be replaced by "same = identity"=20 (PSK identity for PSK, public key for RPK, CN for certificate) for = authenticated=20 peer or "same session" for non-authenticated. In case you want to allow = TLS=20 renegotiation you should add "same cipher" too. But TLS renegotiation = seems to=20 be not advisable for DTLS 1.2 : https://tools.iet= f.org/html/rfc7925#section-17=20 and removed to DTLS 1.3 last time I looked at it.

  I initially think about that for observe request, but maybe it = can be=20 generalized to all request/response correlation.

  Here some discussion about this idea = :
     -=20 https://www.ietf.org/mail-archive/web/core/current/msg08019.html
=     =20 - https://www.ietf.org/mail-archive/web/core/current/msg08004.html

=

Simon

Le 08/06/2017 =C3=A0 11:08, Carsten Bormann = a =C3=A9crit=20 :
On Jun 8, 2017, at 10:17, Kraus Achim =
(INST/ECS4) mailto:Achim.Kraus@bosch-si.com<=
/A> wrote:

It's still unclear to me, if =
this should be considered to be the "same epoch" in the meaning of =
RFC7252.  =20

I pointed to that last summer (https://www.ietf.org/mail-archive/web/core/current/msg07816.html), =
but I could get clarification on that.

I think that we can agree that the =
current definition is
=E2=80=94 not fully clear
=E2=80=94 unrealistic in certain implementation environments (so it may =
not actually be implemented)
=E2=80=94 unnecessarily restrictive.

Now the next question is what definition would
=E2=80=94 make sense from an implementers=E2=80=99 point of view
=E2=80=94 not be unnecessarily restrictive
=E2=80=94 retain the desirable security properties of the current =
restrictive definition
- be clear
- maybe also make sense for DTLS 1.3 (which isn=E2=80=99t fully baked =
yet).

(And then we have to figure out the process for fixing it =E2=80=94 that =
is not too hard once we know the extent of the change that needs to me =
made.  E.g., an RFC updating RFC 7252.)

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/=
mailman/listinfo/core

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0105_01D2E17F.D4FB9780--