Authentication/Confidentiality for OSPFv3
draft-ietf-ospf-ospfv3-auth-08

Authors have been corresponding with Sam; latest update from Sam follows.

From: Sam Hartman
Subject: Re: OSPFv3 Security: Updated Draft..
Date: Fri, Dec 16 12:55:49
To: Mukesh Gupta
Cc: acee@cisco.com, rohit@utstar.com, nmelam@juniper.net,
    housley@vigilsec.com, zinin@psg.com, fenner@research.att.com

Hi.

We're getting closer but I still see some significant problems:

1) Section 6 specifies that the implementation must support a specific
    SPD selection function but does not describe properties of that
    function.  Presumably the primary property you need is the
    ability to choose an SPD based on interface.
Do you need anything else?

2) You still do not specify where the IPsec protection barrier is.  We
    had a long discussion on that topic and the results of the
    discussion need to make it into the draft.

3) Section 11 is still not compatible with RFC 3401.

    A) You cannot specify an interface in an SPD.  Instead, you can
    have an SPD selected based on interface and put rules into that
        SPD that are appropriate for the selected interface.



    B) There are not separate inbound and outbound rules.  Rules apply
        equally to inbound and outbound traffic.


    C) Use the term protect rather than apply.  Use the term discard
        rather than drop.


So you're going to need to rewrite section 11 to say that you assume
there is an SPD that will be selected for each outbound interface and
that the rules for a given interface need to be added to that SPD.
You are going to need to be careful describing virtual link rules to
describe which SPDs they need to be added to.  In particular, you
don't want a virtual link OSPF packet received on the wrong interface
to be accepted when one normally would not be accepted.

[Ballot discuss]
This discussed based on comments from Steve Kent and who did a brief
review of the document at my request.  Other comments also come from
my initial review.


Section 6, IPsec requirements does not appear to use the same model of
IPsec as draft-ietf-ipsec-rfc2401bis.  It assumes that the source and
destination interface is part of the traffic selector in the SPD.
This is not true.  It's possible to obtain this effect through
implementation-specific extensions to IPsec such as multiple SPDs and
a SPD-selection function that looks at source interface.  It is not
clear to me that there is only one way of getting this effect nor that
most implementations will tend to choose the same mechanism.

        - section 6: the reference to "interface index" and
"direction" are a bit odd, relative to both 2401 and 2401bis SPD
descriptions. Directionality is implicit in policy specifications, in
that for IPsec-protected traffic, we always created paired SAs. The
phrase "interface index" does not appear in either 2401 or 2401bis.
at this point in the text, it is not clear what the intent is when
this term is used.

        - section 7: the discussion of static SA management here seems
inconsistent with the mandated support for "Dynamic IPsec rule
configuration" at the end of section 6.  How are these virtual link
SAs created if only manual configuration is supported?

        - Section 7 (again) the discussion of using the
same SA for inbound and outbound traffic says that this is NOT IPsec,
period. A fundamental concept in IPsec, since the very early days, is
that an SA is unidirectional.
        - Section 9 does not describe how the SAs for virtual links are keyed; similar to comment on section 7.

        - Section 11  The rules are incomplete (missing bypass rules)
and do not seem to fit the model for RFC 2401bis very well.  Are you
assuming multiple SPDs with one per interface?  Are you assuming a
single SPD?  Where is the protection barrier?

[The following comments from Steve Kent may be useful in understanding
how to fit this work to the 2401bis model.]


Using the 2401bis model, this is all a lot simpler, I think (except
for their multicast SA problem.) Since the user of IPsec is the OSPF
host inside a router, the simplest way to talk about IPse use here is
to imagine it as a an entity like an end system host. It is on the
protected side of the IPsec barrier, and the rest of the Internet is
on the unprotected side. So, all traffic emitted by the OSPF host,
and all traffic directed to it, transit the barrier, irrespective of
the physical interface via which the traffic enters or exits the
router. This avoids the need to worry about bypassing subscriber
traffic or accidentally grabbing subscriber traffic that happens to
use IPsec, because such traffic is NOT legitimately directed to this
OSPF host. The forwarding function on the unprotected side of the
barrier, as noted in the 2401bis processing model, deals with
directing outbound IPse protected traffic to the right physical
interface.  I'm not sure how the virtual links work here, as I did
not understand section 9, but I do think this will be easier to deal
with under the new model.

[Ballot comment]
The discussion of how often manual keys need to be changed is poorly
worded.  It states as facts that hmac-SHA1 is more secure than
hmac-MD5 and that DES plus hmac-MD5 is more secure than hmac-MD5
alone.  These are reasonable assumptions to make, but they are not
facts; the section would be improved by stating these as assumptions.

[Ballot comment]
I cannot support a security solution for OSPF that only supports
manual keying for broadcast/multicast networks without understand why
no better options are possible.  Rather than delaying the document to
confirm that we don't have better options, I'll abstain.


If I were not entering an abstain, I'd enter a discuss over at least the follo
wing issues:

Section 6, IPsec requirements does not appear to use the same model of
IPsec as draft-ietf-ipsec-rfc2401bis.  It assumes that the source and
destination interface is part of the traffic selector in the SPD.
This is not true.  It's possible to obtain this effect through
implementation-specific extensions to IPsec such as multiple SPDs and
a SPD-selection function that looks at source interface.  It is not
clear to me that there is only one way of getting this effect nor that
most implementations will tend to choose the same mechanism.


The discussion of how often manual keys need to be changed is poorly
worded.  It states as facts that hmac-SHA1 is more secure than
hmac-MD5 and that DES plus hmac-MD5 is more secure than hmac-MD5
alone.  These are reasonable assumptions to make, but they are not
facts; the section would be improved by stating these as assumptions.

Alex/Bill,

06 version of the OSPFv3 Security draft addresses the
following comments/issues:

From IESG:
- Discuss about how much protection OSPF has for replay
  attacks without the security enabled
- Add references to 3602 and 2404
- Analyze and recommend values of rekeying interval and KeyRolloverInterval
- Spell out in the security considerations that one router can impersonate
another
- Larger routing security not considered here (refer to rpsec)
  i.e., "What's left to worry about after you deploy this?"
- Refer to rpsec drafts

From authors:
- MUST requirement for hex format keys.  This will significantly
  increase the entropy of the keys.

[Ballot discuss]
The Security Considerations section needs to discuss matters in the purview of the rpsec wg -- that's the real threat.  Such concerns fall under the heading of "residual threats", which must always be in a Security Considerations section.

Authors have not yet completely addressed IESG comments:

From: Mukesh Gupta
Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-05.txt
Date: Mon, 25 Oct 2004 14:01:30 -0500
To: OSPF@PEACH.EASE.LSOFT.COM
Reply-to: Mailing List

Hi All,

We have addressed the following things in this revision:

- Changed rule 3 & 5 to add OSPF with AH/ESP.
- Rules for interfaces and virtual links were separated to remove iface
column
- Made AES-CBC & HMAC SHA1 a MUST and other non-stream ciphers a SHOULD.
- Use of stream ciphers with manual keys is now prevented
- Made changing keys a "SHOULD" from "MAY".
- Mentioning that the SAs are per-link (as defined in OSPFv3 RFC).
Therefore, all the OSPF instances have to use same SA.
- Referring to New version of IPsec drafts or old versions of IPsec RFCs now
- Some paragraphs were rephrased for clarity
- ADDed OSPFv2 in References
- Moved to the newer boilerplate

This draft does NOT address all the comments that we received
from IESG and on the list.

We will be submitting another revision to address the remaining
changes.

Please review this version and see if we got things right.

Regards
Mukesh & Suresh

[Ballot discuss]
The -05 version of this document is greatly improved over the -04
  version.  Nice work.  However, I still have two concerns.

  In the Security Considerations section, the document needs to prevent the
  use of stream ciphers with manual key management.  I think that this
  is easily done by adding another bullet to the list of limitations
  that already appears in that section.

  To ensure interoperability, AES-CBC and HMAC-SHA-1 are mandatory to
  implement.  As such, the ESP with AES-CBC specification (RFC 3602) needs
  to be a normative reference.  Also, a normative reference is needed for
  HMAC-SHA-1.  I assume that HMAC-SHA-1-96 will be used as specified in
  RFC 2404.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

A DISCUSS that has been turned into a comment:

I can not find in section 8 where it defines what keying shall be used for
virtual links.  Either the intention is that a single key be used over the
whole domain, which would need to be stated, with its security
implications, or else IKE needs to be used, in which case that needs to be
stated, along with moving IKE to a normative reference.  Or maybe there is
some alternative I have missed.

My grumble: With all the work that's been sunk into multicast security, is it really not possible to do any better than "broadcast media requires static keying with one key per medium"?

However, I trust Steve and Russ to do as well as can be done over this.

[Ballot comment]
> 2. OSPFv2 to OSPFv3
>
>    Security concerns MUST be taken away from OSPFv3 protocol and IPv6
>    stack MUST provide inherent security to OSPFv3 by using AH/ESP
>    extension headers.  It means OSPFv3 protocol MUST NOT receive any
>    unauthenticated packets.  As OSPFv2 has its own security mechanisms,
>    no inherent security needs to be provided by the IPv4 stack.  As
>    OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction
>    between the packets can be easily made by IP version.

wording poor. sounds like you MUST use AH/ESP. Surely, it is optional
when one chooses to use it.

>    Encryption and Authentication Algorithms
>      The implementations MUST be conformant to the RFCs that describe
>      mandatory-to-implement algorithms for use with ESP and AH.

Cite the RFC please...

>    So, all the neighbor routers on a network/subnet MUST use the same SA
>    and the same SA MUST be used for inbound and outbound processing.

and how does this impact replay protection?

>    Different SA than the SA of underlying interface MUST be provided for
>    virtual links.  Packets sent out on virtual links use unicast site-
>    local or global IPv6 addresses as the IPv6 source address and all the
>    other packets use multicast and unicast link local addresses.  This
>    difference in the IPv6 source address is used in order to
>    differentiate the packets sent on interfaces and virtual links.

given the deprecation of site local, can the above be rewritten to say
"non-link local" rather than mentioning site-local?

Also, is this necessary? Why do use of virtual links have standards
implications? In general, virtual links are just implementation
tricks. Protocols should not  need to know about them.

>  links are learnt during the routing table build up process.  The

s/learnt/learned/

>    To maintain the security of a link, it may be desirable to change the
>    key values from time to time.  The following three-step procedure MAY
>    be provided to rekey the routers on a link without dropping OSPFv3
>    protocol packets or disrupting the adjacency.

This is only a MAY? Seems like a SHOULD or MUST.

Security considerations seems pretty weak..

[Ballot discuss]
The first sentence of section 2 is very confusing, and it contains two MUST
  statements.  It says:
  >
  > Security concerns MUST be taken away from OSPFv3 protocol and IPv6
  > stack MUST provide inherent security to OSPFv3 by using AH/ESP
  > extension headers.
  >
  I propose the following replacement text for the first two sentences:

    The IPv6 stack, by making use of either AH or ESP, MUST provide integrity
    and authentication of all datagrams delivered to OSPFv3.  The IPv6 stack
    MAY also provide confidentiality of datagrams delivered to OSPFv3.

  I also find the last paragraph of section 2.  I believe separate paragraphs
  on confidentiality and authentication is desirable, but I cannot figure
  out the MUST statement that is intended for authentication.  See the
  following attempt to create replacement text.

    Authentication of selected portions of IPv6 header, selected portions
    of extension headers, and selected options can be provided when AH is
    employed.  If this form of authentication is provided, it MUST ...

    Confidentiality can be provided when ESP is employed.  When
    confidentiality is provided, it MUST cover the entire OSPFv3 header
    and data.

  The last paragraph of section 3 does not cover ESP integrity checking.
  Also, AH delivers cleartext packets; they are not encrypted.  I propose
  the following alternate text:

    OSPFv3 packets that are not protected with AH or ESP MUST be silently
    discarded.
   
    When the Integrity Check Value (ICV) is incorrect in either AH or ESP,
    the encapsulated OSPFv3 packets MUST be silently discarded.

  In the Security Considerations section, the document needs to prevent the
  use of stream ciphers with manual key management.

  To ensure interoperability, I expected a set of mandatory to implement
  algorithms for ESP and AH.

[Ballot discuss]
From Spencer Dawkins' review:

I can not find in section 8 where it defines what keying shall be used for
virtual links.  Either the intention is that a single key be used over the
whole domain, which would need to be stated, with its security
implications, or else IKE needs to be used, in which case that needs to be
stated, along with moving IKE to a normative reference.  Or maybe there is
some alternative I have missed.

My grumble: With all the work that's been sunk into multicast security, is it really not possible to do any better than "broadcast media requires static keying with one key per medium"?

[Ballot discuss]
From Spencer Dawkins' review:

I can not find in section 8 where it defines what keying shall be used for
virtual links.  Either the intention is that a single key be used over the
whole domain, which would need to be stated, with its security
implications, or else IKE needs to be used, in which case that needs to be
stated, along with moving IKE to a normative reference.  Or maybe there is
some alternative I have missed.

[Ballot comment]
Not blocking since the blocking portion of it is covered in Steve's DISCUSS, but I
also found Section 9 on Changing Keys fairly weak and Section 6's discussion of
manual keying and multicast light.  I think the reader would benefit from
a discussion of how the limitations on manual keying for multicast will affect
the deployment of this mechanism--does it imply, for example, something
about appropriate multicast group sizes?

[Ballot discuss]
Given the reliance on static keying, there needs to be discussion of key rollover mechanisms (as well as key change guidelines similar to those in RFC 3562).  Note that this is not an easy problem, since uncoordinated key changes can eliminate the connectivity needed for easy changes on other routers.  I suggest a requirement for a key overlap period.  (This also helps address the replay issue.)  Note the implementation constraints: a single protocol handler must have the ability to accept input from more that one SPI from a single source. 

The IPsec rules in Section 10 are not correct.  More accurately, rules 3 and 5 are imprecise; they say to accept AH/ESP packets, where as what they should say is to accept AH/ESP+OSPF packets. 

The Security Considerations section needs to discuss matters in the purview of the rpsec wg -- that's the real threat.  Such concerns fall under the heading of "residual threats", which must always be in a Security Considerations section.

[Ballot discuss]
Section 2:
The text says "It means OSPFv3 protocol MUST NOT receive any unauthenticated packets".  Later in the same section, the text says:

"Authentication and confidentiality, if provided, MUST be provided to
the entire OSPFv3 header and data.  Authentication to the selected
portions of IPv6 header, selected portions of extension headers and
selected options MAY also be provided optionally."

How can these be "if provided" and "MAY also be provided optionally" if there MUST NOT be any unauthenticated packets?

Section 5:
Please cite a reference to describe "IPsec in transport mode MUST be supported".

Please cite the RFCs "that describe mandatory-to-implement algorithms for use with ESP and AH".

[Ballot discuss]
Section 2:
The text says "It means OSPFv3 protocol MUST NOT receive any unauthenticated packets".  Later in the same section, the text says:

"Authentication and confidentiality, if provided, MUST be provided to
the entire OSPFv3 header and data.  Authentication to the selected
portions of IPv6 header, selected portions of extension headers and
selected options MAY also be provided optionally."

How can these be "if provided" and "MAY also be provided optionally" if there MUST NOT be any unauthenticated packets?

Section 5:
Please cite a reference to support "IPsec in transport mode MUST be supported".

Please cite the RFCs "that describe mandatory-to-implement algorithms for use with ESP and AH".

Subject: Re: WG Last Call for draft-ietf-ospf-ospfv3-auth-04.txt  -
        Authentication/Confidentiality for OSPFv3
Date: Tue, 13 Jan 2004 13:47:33 -0500
From: Acee Lindem
To: OSPF WG List , Bill Fenner
    , Alex Zinin , IESG Secretary
   
Organization: Redback Networks

This WG last call has completed and the subject document will be submitted
to the IESG for evaluation.