Subject: Re: [lisp] #3: lisp-ms security mechanism between ITR and map resolver

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 08 Dec 2009 10:11:03 -0000

#3: lisp-ms security mechanism between ITR and map resolver
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:     
    Type:  technical              |      Status:  new
Priority:  major                  |   Component:  ms 
Severity:  -                      |    Keywords:     
----------------------------------+-----------------------------------------

Old description:

> Currently, the interface between the ITR and map resolver has two
> security concerns.
>
>  * There is no integrity protection of the exchange between the ITR and
> map resolver
>
>  * An ITR accepts a reply from any ETR, which makes it hard to add
> security.
>
> The only protection of the map reply is that it needs to have the same
> nonce as the map request.  Long term, that is unlikely to be good
> enough.  It will be impossible to provide protection against on-path
> attackers who can observe the nonce unless cryptographic security is
> used.  I understand that the alt does not currently provide
> cryptographic security.  I don't know whether we'll conclude that is
> adequate (although suspect we'll decide it's the best we can do for
> the experimental version).  However even if that is adequate, it seems
> like in many deployments the path between the ITR and map resolver is
> more open to attack than the path over the alt.  For this reason I
> suspect that cryptographic security is needed to the map resolver even
> if it is not provided in the alt.
>
> If others disagree, I'm happy to hold this issue open until we've
> actually done security analysis of the ITR map resolver security.  I'm
> not comfortable closing this issue before that analysis.
>
> If cryptographic security is provided between the ITR and map
> resolver, it must meet the same requirements as security between the
> ETR and map server.

New description:

 Currently, the interface between the ITR and map resolver has two
 security concerns.

  * There is no integrity protection of the exchange between the ITR and
 map resolver

  * An ITR accepts a reply from any ETR, which makes it hard to add
 security.

 The only protection of the map reply is that it needs to have the same
 nonce as the map request.  Long term, that is unlikely to be good
 enough.  It will be impossible to provide protection against on-path
 attackers who can observe the nonce unless cryptographic security is
 used.  I understand that the alt does not currently provide
 cryptographic security.  I don't know whether we'll conclude that is
 adequate (although suspect we'll decide it's the best we can do for
 the experimental version).  However even if that is adequate, it seems
 like in many deployments the path between the ITR and map resolver is
 more open to attack than the path over the alt.  For this reason I
 suspect that cryptographic security is needed to the map resolver even
 if it is not provided in the alt.

 If others disagree, I'm happy to hold this issue open until we've
 actually done security analysis of the ITR map resolver security.  I'm
 not comfortable closing this issue before that analysis.

 If cryptographic security is provided between the ITR and map
 resolver, it must meet the same requirements as security between the
 ETR and map server.

--

Comment(by hartmans-ietf@…):

 This issue needs to wait until there is a framework of security properties
 in which to have the discussion. Reception to date has been negative,
 although no case has been presented in which this would be part of an
 overall security discussion.  This issue was opened as a placeholder to
 make sure that discussion does eventually happen; it remains so.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/3#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Michael Menth <[email-masked]>
Date: Tue, 08 Dec 2009 11:23:38 +0100

Hi,

the FIRMS architecture has already the desired security features. Maybe 
some of its ideas are useful for the security discussion.
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth09-FIRMS.pdf

Regards,

Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Menth <[email-masked]>
Date: Wed, 09 Dec 2009 00:23:39 +0100

Hi,

just a clarification, Joel pointed me to this. In our paper we have not 
explicitly covered how the transport between MR and ITR can be secured 
which is the topic of tracker issue #3. As the ITR knows its MR (through 
configuration) and possibly vice-versa, it should not be too difficult 
to use standard techniques like TLS for transmission. Probably I miss a 
point here?

I think it's far more ambitious to secure the transmission from the 
authoritative source of the mappings (ETRs in most mapping systems, 
map-bases (MBs) in FIRMS) to the MRs. I have not seen a tracker issue 
for this part of the mapping system. That is what we have presented a 
solution for in the mentioned paper. It cannot be directly copied to 
LISP+ALT, but it might provide some ideas in this context.
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth09-FIRMS.pdf 

Best wishes and sorry for the confusion,

    Michael

Michael Menth schrieb:
> Hi,
>
> the FIRMS architecture has already the desired security features. 
> Maybe some of its ideas are useful for the security discussion.
>> Reporter:  hartmans-ietf@…        |       Owner:         Type:  
>> technical              |      Status:  new
>> Priority:  major                  |   Component:  ms Severity:  
>> -                      |    Keywords:

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Dec 2009 20:04:07 -0500

>>>>> "Michael" == Michael Menth <[email-masked]> writes:

    Michael> Hi, just a clarification, Joel pointed me to this. In our
    Michael> paper we have not explicitly covered how the transport
    Michael> between MR and ITR can be secured which is the topic of
    Michael> tracker issue #3. As the ITR knows its MR (through
    Michael> configuration) and possibly vice-versa, it should not be
    Michael> too difficult to use standard techniques like TLS for
    Michael> transmission. Probably I miss a point here?

The open question is mostly whether it buys us anything we need.

    Michael> I think it's far more ambitious to secure the transmission
    Michael> from the authoritative source of the mappings (ETRs in most
    Michael> mapping systems, map-bases (MBs) in FIRMS) to the MRs. I
    Michael> have not seen a tracker issue for this part of the mapping
    Michael> system. That is what we have presented a solution for in
    Michael> the mentioned paper. It cannot be directly copied to
    Michael> LISP+ALT, but it might provide some ideas in this context.
    Michael> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth09-FIRMS.pdf

I think we know we need to discuss security between the source of the
mapping information and its consumer.  This is a little more involved
even in the requirements space than a simple tracker issue.  I've
started workin through my thoughts on the matter on the Security01 page
on the wiki.  I'm excited to receive your paper and will definitely be
reading it.