weigengyu
2017-06-01 15:14:14 UTC
Hi Jim,
Here we use Califorium fore CoAP/DTLS/UDP/IP and CoAP/DTLS/SMS tests.
The epoch is changed after receiveing ChangeCipherSpec at the server side.
Regards
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----ÔÊŒÓÊŒþ-----
From: Jim Schaad
Sent: Monday, May 15, 2017 11:26 PM
To: 'Klaus Hartke'
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs
At this point I would have to ask why similar language is not in the TLS
draft as well.
Note however that this has nothing to do with epochs and everything to do
with additional authentication. I think that an errata is called for to
clarify this.
It turns out that my DTLS libraries are unable to give me the fact that an
epoch has changed, but would know if additional authentication was done.
Two very different operations.
Jim
-----Original Message-----
From: Klaus Hartke [mailto:***@tzi.org]
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad <***@augustcellars.com>
Cc: ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] DTLS and Epochs
Hi Jim,
the requirement was added for the case that the epoch changes due to client
or server authentication.
Example:
1. A client connects to a server using DTLS. The server
authenticates with a server certificate; the client
is unauthenticated.
2. The client sends a request that requires the client
to be authenticated.
3. The server requests the client to authenticate.
4. The client authenticates with a client certificate;
a new epoch starts.
5. The server processes the request, assuming it comes
from the now authenticated client. Oops!
Requiring that the request is sent in the same epoch as the response
prevents this. It seems the language in the RFC was made too broad when
trying to say that, though. An erratum could make it more precise.
Klaus
It turns out that my DTLS libraries are unable to give me the fact that an
epoch has changed,
but would know if additional authentication was done. Two very different
operations.
It is not known what libraries are used.epoch has changed,
but would know if additional authentication was done. Two very different
operations.
Here we use Califorium fore CoAP/DTLS/UDP/IP and CoAP/DTLS/SMS tests.
The epoch is changed after receiveing ChangeCipherSpec at the server side.
Regards
Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----ÔÊŒÓÊŒþ-----
From: Jim Schaad
Sent: Monday, May 15, 2017 11:26 PM
To: 'Klaus Hartke'
Cc: ***@ietf.org
Subject: Re: [core] DTLS and Epochs
At this point I would have to ask why similar language is not in the TLS
draft as well.
Note however that this has nothing to do with epochs and everything to do
with additional authentication. I think that an errata is called for to
clarify this.
It turns out that my DTLS libraries are unable to give me the fact that an
epoch has changed, but would know if additional authentication was done.
Two very different operations.
Jim
-----Original Message-----
From: Klaus Hartke [mailto:***@tzi.org]
Sent: Monday, May 15, 2017 5:02 AM
To: Jim Schaad <***@augustcellars.com>
Cc: ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] DTLS and Epochs
Hi Jim,
the requirement was added for the case that the epoch changes due to client
or server authentication.
Example:
1. A client connects to a server using DTLS. The server
authenticates with a server certificate; the client
is unauthenticated.
2. The client sends a request that requires the client
to be authenticated.
3. The server requests the client to authenticate.
4. The client authenticates with a client certificate;
a new epoch starts.
5. The server processes the request, assuming it comes
from the now authenticated client. Oops!
Requiring that the request is sent in the same epoch as the response
prevents this. It seems the language in the RFC was made too broad when
trying to say that, though. An erratum could make it more precise.
Klaus
I am working on getting my DTLS code to work correctly and I have come
across something that I do not understand. I did not see any messages
in the mailing list that dealt with this so I would like to get an
explanation if possible.
RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the
same. I can understand the reasoning behind the id and session being
the same, however I am unsure of the reason that the epoch would need
to be the same as well. I cannot see of a reason why the epoch should
matter. The security session is still the same. I could understand
that there would be a reason to kill an association if additional
client or server authentication information had been passed along, but
while that would change the epoch, an epoch can change just because
enough messages have been sent over the pipe.
Can somebody please explain the reasoning to me.
Jim
across something that I do not understand. I did not see any messages
in the mailing list that dealt with this so I would like to get an
explanation if possible.
RFC 7252 states that a response is not to be correlated with a request
unless the message id, the DTLS session and the DTLS epoch are the
same. I can understand the reasoning behind the id and session being
the same, however I am unsure of the reason that the epoch would need
to be the same as well. I cannot see of a reason why the epoch should
matter. The security session is still the same. I could understand
that there would be a reason to kill an association if additional
client or server authentication information had been passed along, but
while that would change the epoch, an epoch can change just because
enough messages have been sent over the pipe.
Can somebody please explain the reasoning to me.
Jim