Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Wed, 27 April 2016 19:32 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6E212D547; Wed, 27 Apr 2016 12:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ePbI1KJWQLvL; Wed, 27 Apr 2016 12:32:04 -0700 (PDT)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB39612DB5E; Wed, 27 Apr 2016 12:32:03 -0700 (PDT)
Received: by mail-pf0-x242.google.com with SMTP id e190so6699589pfe.0; Wed, 27 Apr 2016 12:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ikJOniF4W9uxmTWnw+69pvweom2G45HWHGvD4IGo/Uc=; b=KBUpKUqDW2EnH07o/FrRDzF37PYkQYrQF95ytSP7srhTW70HnQayrD5kdUFASi2W7h t3eLCJX8hBuxTL5dOpdn21Ukf1cPMLzJVcMeYX1zgB9pVXxoCB8yfrw8CgOrHncQAp9W sMSqqvPLQkjTQwN2l9chRRyAG/YDhw+k8IyPqLYvEvOZ8ijNCl2RK+OnBvYB8KvwHZpo aOJkNSuRB0g2RmsImXKtKVbXDt2S1nbd/N2ktrymFrlcP0DpyOntmdo6ei7nN6T8zST2 qUC3zfoP3MmNp9iLcvL/h3sObRrGMgKJZBtr0EIbjxNdvF6dEwSD5LFavchIuxdnwPxV rZOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ikJOniF4W9uxmTWnw+69pvweom2G45HWHGvD4IGo/Uc=; b=jO+D60AuU3L5gO0rjBomzs04BdMFTGm29X5obpXsuFbB8Yc27r6aheyPKFn5nv9awT x8GlwNJS49DIGEpagqKJtdF7SUoEnTAcQMkMOMPIS3Y3mbmwc43nB7Bs2K1DV9lvgnzJ dMCI9JqAKqvKkVfBiXTO6eId5NB7/ijDzG15IFEilbnWq4lAIMiOdsEZfJktIKa9uC/j jCrhncDS4QEhW2swip7MolVG1Idbp/R4NwSxxyG4sp/GfioFGlY+kkDYgnai3w7KrkJ4 gP/rVU/9D2D2Q5riLxQ3RLXYAgksUDYmIxS/CA1zLX/xqXBzY+1VSfCIi4k2sxtDd1cz Z4Jg==
X-Gm-Message-State: AOPr4FVfE+P1aUVBj9D98rukeXsIVWysBxabFfHedDoy+MPIMaPSWniAvVPfVfTcXq60Hg==
X-Received: by 10.98.70.67 with SMTP id t64mr14506623pfa.110.1461785523509; Wed, 27 Apr 2016 12:32:03 -0700 (PDT)
Received: from Pushpasiss-MacBook-Pro.local ([171.48.10.246]) by smtp.gmail.com with ESMTPSA id q20sm8565044pfi.63.2016.04.27.12.32.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 12:32:02 -0700 (PDT)
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, Hannes Gredler <hannes@gredler.at>
References: <A72D09E9-4622-41DB-8EA0-62518AA9CA7A@nrl.navy.mil> <5719D3FA.4070402@gredler.at> <7609B084-63E4-4341-912B-2083E88F6CB8@nrl.navy.mil>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Message-ID: <572113AE.80602@gmail.com>
Date: Thu, 28 Apr 2016 01:01:58 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <7609B084-63E4-4341-912B-2083E88F6CB8@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="------------090507040509050601080109"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/1jLWNds3RgEp5HINlfQeC0_-Ung>
Cc: draft-ietf-isis-node-admin-tag.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] sectdir review of draft-ietf-isis-node-admin-tag-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 19:32:06 -0000

Hi Catherine,

Please let me know if the following text clarifies it better or not.

"
6.  Security Considerations

    Node administrative tags, like link administrative tags [RFC5305],
    can be used by operators to indicate geographical location or other
    sensitive information.  The information carried in node
    administrative tags, like link administrative tags, can be leaked to
    an IGP snooper.  Hence this document does not introduce any new
    security issues.

    Advertisement of tag values for one administrative domain into
    another involves the risk of misinterpretation of the tag values (if
    the two domains have assigned different meanings to the same values),
    and may have undesirable and unanticipated side effects.

    Security concerns for IS-IS are already addressed in [ISO10589],
    [RFC5304], and [RFC5310] and are applicable to the mechanisms
    described in this document.  Extended authentication mechanisms
    described in [RFC5304] or [RFC5310] SHOULD be used in deployments
    where attackers have access to the physical networks and nodes
    included in the IS-IS domain are vulnerable.
"

Thanks and Regards,
-Pushpasis

On 4/27/16 1:36 AM, Catherine Meadows wrote:
> Hannes:
>
> My apologies, I could have been a little more clear.
>
> The security considerations section begins with a security consideration:
>
> Node administrative tags may be used by operators to indicate
>    geographical location or other sensitive information.  The
>    information carried in node administrative tags could be leaked to an
>    IGP snooper.
>
> This doesn’t come with a citation of any other document, so I assumed 
> it was “new”, and was confused when the
> next sentence said the document does not introduce any new security 
> concerns.   If this security consideration also applies to
> RFC5130 and RFC5305, you could cite those (although they do not 
> address this particular issue in their security
> concerns section it would still show that you are not introducing any 
> new security concerns).
>
>
> Cathy
>
>
>
>
> Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil 
> <mailto:catherine.meadows@nrl.navy.mil>
>
>> On Apr 22, 2016, at 3:34 AM, Hannes Gredler <hannes@gredler.at 
>> <mailto:hannes@gredler.at>> wrote:
>>
>> catherine,
>>
>> i fail to see how this does introduce *new* security concerns.
>>
>> background:
>>
>> we have in IS-IS two existing tagging mechanism's:
>>
>> 1) admin-groups for links
>> https://tools.ietf.org/html/rfc5305#section-3.1
>>
>> 2) prefix-tags for prefixes
>> https://tools.ietf.org/html/rfc5130#section-3.1
>>
>> both "tagging-spaces" are local administered and have
>> no global significance.
>>
>> the purpose of draft-ietf-isis-node-admin-tag-08 is to
>> add support for a third tagging method which allows tagging
>> of an entire node using local administered tagging space.
>> (same operational spirit as in 1) and 2) )
>>
>> now my question(s):
>>
>> - why is adding of an local-administered tag with no implied
>>  semantics considered to be security relevant ?
>>
>> - what specific (apparently mis-)wording in
>>  draft-ietf-isis-node-admin-tag makes you think
>>  it is security relevant ?
>>
>> /hannes
>>
>> On 4/21/16 19:36, Catherine Meadows wrote:
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all
>>> IETF documents being processed by the IESG.  These comments were written
>>> primarily for the
>>> benefit of the security area directors.  Document editors and WG chairs
>>> should treat these comments
>>> just like any other last call comments.
>>>
>>> This draft describes an extension to the IS-IS routing protocol, that
>>> allows tagging and grouping of nodes
>>> in an IS-IS domain.  This makes it possible to increase the efficiency
>>> of route and path selection, since the tags
>>> give information about a router’s capabilities.
>>>
>>> The Security Considerations section correctly identifies one of the main
>>> security risks of using such tags:  they may leak
>>> sensitive information about, e.g., geographical location.   However, I’m
>>> confused by the statement following that:
>>>
>>> “This document does not introduce any new security concerns.  Security
>>> concerns for IS-IS are already addressed in
>>> [ISO10589], [RFC5304], and [RFC5310] are are applicable to the
>>> mechanisms described in this document.”
>>>
>>> As far as I can tell, this document *does* introduce new security
>>> concerns, because the tags may reveal sensitive
>>> information that may not have been made available otherwise.  Moreover,
>>> RFCs 5304 and 5310 concern authentication, not
>>> secrecy, and so do not address information leakage at all.  My own
>>> suggestion
>>> for a recommendation would be that implementors should weigh the
>>> benefits of putting certain kinds of information on tags
>>> versus the risk of its being used by an attacker, and make their
>>> decisions accordingly.  This would not be a SHOULD a MUST
>>> recommendation by the way, but simply advisory.
>>>
>>> I’m not sure what is meant by the last sentence in this paragraph:
>>>
>>>  Extended authentication mechanisms described in [RFC5304] or [RFC5310]
>>> SHOULD be used in
>>>    deployments where attackers have access to the physical networks and
>>>    nodes included in the IS-IS domain are vulnerable.
>>>
>>> Is this addressing the problem of sensitive information on tags?  If so,
>>> you need to say how.   If it is addressing
>>> spoofing of tags, it should be given its own paragraph, and the threat
>>> you are talking about should be made clear.
>>>
>>> In the last paragraph, on the misattribution of tags from different
>>> domains, what would you recommend for mitigating against
>>> this problem?  Also, since this is in the security considerations
>>> section, you should say something about how an attacker
>>> could take advantage of it.
>>>
>>> In my opinion, the Security Considerations section needs a major
>>> revision.  However,
>>> I consider this document Almost Ready, because the purpose of the
>>> revision would be mainly to make the section more clear, not to address
>>> any overlooked security problems.
>>>
>>>
>>>
>>>
>>> Catherine Meadows
>>> Naval Research Laboratory
>>> Code 5543
>>> 4555 Overlook Ave., S.W.
>>> Washington DC, 20375
>>> phone: 202-767-3490
>>> fax: 202-404-7942
>>> email: catherine.meadows@nrl.navy.mil 
>>> <mailto:catherine.meadows@nrl.navy.mil>
>>> <mailto:catherine.meadows@nrl.navy.mil>
>>>
>