Sorry, yes, it is the MS, not the MR, who provides the information to
construct the key, since it is the MS who is generating the notifies.
Sorry I still cross them up.
Yours,
Joel
On 3/31/2020 8:01 PM, Dino Farinacci wrote:
Yes, but that’s a new precedent requiring the MR to store state. We should try
to make it lighter weight. And you can’t do what you want on the MR, because
its the MS’s OTK as spec’ed today that is passed to the ETR.
Dino
On Mar 31, 2020, at 4:58 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
We could reuse the OTK directly. My actual inclination would be for the MR to
send back (via the ETR) some data which, when combined with the OTK, produced a
separate key for use with the notify messages. Clearly, the MR would have to
store whatever security key we want it to use as long as the subscription
persisted.
Yours,
Joel
On 3/31/2020 7:27 PM, Dino Farinacci wrote:
I may have missed something, but I think that in the case of the first notify,
it does actually start at the Itr.
Specifically, it starts with an ItR sending a subscribe request. The MS
responds to that with a notify. What I am suggesting is that (when security is
desired) the Itr includes the same kind of information in its subscribe that
goes into lisp-sec. And that the reply, instead of going directly from the MS
back to the ITR goes through the ETR so that the rest of the lisp-sec
procedures can be applied.
Yes, and in that Subscribe-Request you can include an OTK. But that
one-time-key would be used more than one time. To send the Map-Notify to reply
with the RLOC-set to the ITR as well as acknowledger from the Map-Server that
subscription has been accepted. But then the one-time-key would have to be
*stored* in the Map-Server and then used later when the RLOC-set changes to
send an unsolicited Map-Notify. So the one-time-key would be “two time” and we
would set a precedent to make it no longer ephemeral. In previous cases, the
OTK was not stored anywhere.
I would then use that as a bootstrap, putting necessary secrets to create the
key information so that the MS can sign and the ITR can verify future notifies
that go directly from the MS to the ITR.
If the working group believes that the OTK should be stored and then used
again, then both the Map-Server and ITR would have to store it. In the original
case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is
received. But the Map-Server would have to store it indefinintely (per ITR that
subscribes).
Dino
Yours,
Joel
On 3/31/2020 1:33 PM, Dino Farinacci wrote:
thinking about Alberto's request, and reading the document, I wondered if the
security could be improved by sending the first notify back via the ETR, and
coupling it to LISP-SEC to protect the information and provide needed keys for
further messages? It seems like we do need a way to protect the notifications,
and requiring associations from every ITR to every MS who may provide
notifications seems impossible.
You can’t use LISP-SEC because the transactional nature of it starts with an
ITR and a one-time-key, that is used to signed Map-Replies returning to it.
For Map-Notify messages send from Map-Server via ETR, there would be no ITR
one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t
derive it. Note with LISP-SEC the map-server one-time-key is derived from the
ITR’s one-time-key in the Map-Request.
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
