Subject: [Isis-wg] draft-ietf-isis-hmac-03.txt

From: Tony Li <[email-masked]>
Date: Wed, 27 Jun 2001 13:07:56 -0700

Folks,

It's equally been forever on this draft as well, but we WOULD appreciate it
if you could look it over again.  It's been submitted as a revised ID.  If
we could get comments in by the end of next week, please.  Assuming that
there are no objections, we will push this forward to Informational.

Ran & Tony

======================================================================

Network Working Group                                                 Tony Li
INTERNET DRAFT                                               Procket Networks
draft-ietf-isis-hmac-03.txt                                       RJ Atkinson
                                                             Extreme Networks
                                                                 20 June 2001

                   IS-IS Cryptographic Authentication

STATUS OF THIS MEMO

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

ABSTRACT

      This document describes the authentication of IS-IS PDUs using the
   HMAC-MD5 algorithm [1].  IS-IS is specified in [2],  with  extensions
   to support IPv4 described in [3].  The base specification includes an
   authentication mechanism  that  allows  for  multiple  authentication
   algorithms.   The base specification only specifies the algorithm for
   cleartext passwords.

        This document proposes an extension to that  specification  that
   allows the use of the HMAC-MD5 authentication algorithm to be used in
   conjunction with the existing authentication mechanisms.

Li & Atkinson              Expires in 6 months               [Page 1]

Internet Draft            IS-IS Authentication              20 June 2001

1. Introduction

        The IS-IS protocol, as specified in ISO 10589, provides for  the
   authentication  of  Link  State  PDUs (LSPs) through the inclusion of
   authentication information as part of the LSP.   This  authentication
   information is encoded as a Type-Length-Value (TLV) tuple.

        The  type  of the TLV is specified as 10.  The length of the TLV
   is variable.  The value of the  TLV  depends  on  the  authentication
   algorithm  and  related  secrets  being used.  The first octet of the
   value is  used  to  specify  the  authentication  type.   Type  0  is
   reserved, type 1 indicates a cleartext password, and type 255 is used
   for routing domain private authentication methods.  The remainder  of
   the TLV value is known as the Authentication Value.

        This  document  extends  the above situation by allocating a new
   authentication type for HMAC-MD5 and specifying  the  algorithms  for
   the  computation  of  the  Authentication  Value.  This document also
   describes modifications to the  base  protocol  to  insure  that  the
   authentication mechanisms described in this document are effective.

      This  document  is a publication of the IS-IS Working Group within
   the IETF, and is a contribution to ISO  IEC  JTC1/SC6,  for  eventual
   inclusion with ISO 10589.

2. Authentication Procedures

        The  authentication  type  used  for HMAC-MD5 is 54 (0x36).  The
   length of the Authentication Value for HMAC-MD5 is 16, and the length
   field in the TLV is 17.

        The  HMAC-MD5  algorithm  requires  a key K and text T as input.
   The key K is the password for the  PDU  type,  as  specified  in  ISO
   10589.   The  text  T  is  the  PDU  to  be  authenticated  with  the
   Authentication Value field inside of the  Authentication  Information
   TLV  set to zero.  Note that the Authentication Type is set to 54 and
   the length of the TLV is set to 17 before authentication is computed.
   When  LSPs  are  authenticated,  the  Checksum and Remaining Lifetime
   fields are set to zero (0) before authentication  is  computed.   The
   result  of the algorithm is placed in the Authentication Value field.

        When calculating the HMAC-MD5 result for  Sequence  Number  PDUs
   and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area
   Authentication string as  in  Level  1  Link  State  PDUs.   Level  2
   Sequence Number PDUs shall use the domain authentication string as in
   Level 2 Link State PDUs.  IS-IS HELLO PDUs SHALL use the  Link  Level

Li & Atkinson              Expires in 6 months               [Page 2]

Internet Draft            IS-IS Authentication              20 June 2001

   Authentication String, which MAY be different from that of Link State
   PDUs.  The  HMAC-MD5  result  for  the  IS-IS  HELLO  PDUs  SHALL  be
   calculated  after the Packet is padded to the MTU size, if padding is
   not disabled.  Implementations that support the optional checksum for
   the  Sequence  Number  PDUs and IS-IS HELLO PDUs MUST NOT include the
   Checksum TLV.

      An implementation  that  implements  HMAC-MD5  authentication  and
   receives  HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect.

      An implementation MAY include HMAC-MD5 Authentication  Information
   in  PDUs even if it does not fully implement HMAC-MD5 authentication.
   This allows an implementation to generate authentication  information
   without   verifying   the  authentication  information.   This  is  a
   transition  aid  for   networks   in   the   process   of   deploying
   authentication.

      An  implementation MAY check a set of passwords when verifying the
   Authentication Value.  This provides a  mechanism  for  incrementally
   changing passwords in a network.

      An  implementation that does not implement HMAC-MD5 authentication
   MAY accept a PDU that  contains  the  HMAC-MD5  Authentication  Type.
   ISes  (routers)  that  implement HMAC-MD5 authentication and initiate
   LSP purges MUST remove the body of the LSP and add the authentication
   TLV.   ISes  implementing  HMAC-MD5  authentication  MUST  NOT accept
   unauthenticated purges.  ISes MUST NOT  accept  purges  that  contain
   TLVs  other  than  the  authentication  TLV.   These restrictions are
   necessary to prevent a hostile system from receiving an LSP,  setting
   the  Remaining  Lifetime  field  to  zero,  and  flooding it, thereby
   initiating a purge without knowing the authentication password.

2.1 Implementation Considerations

        There is an implementation issue just after password rollover on
   an  IS-IS  router  that  might  benefit  from  additional commentary.
   Immediately after password rollover on the router, the router or  IS-
   IS  process  may  restart.   If  this  happens,  this  causes the LSP
   Sequence Number restarts from the value 1  using  the  new  password.
   However,  neighbors  will  reject those new LSPs because the Sequence
   Number is smaller.  The router can not increase its own LSP  Sequence
   Number  because  it  fails  to  authenticate  its  own  old  LSP that
   neighbors keep sending to it.  So the router can not update  its  LSP
   Sequence Number to its neighbors until all the neighbors time out all
   of the original LSPs.  One possible solution to this problem  is  for
   the IS-IS process to detect if any inbound LSP with an authentication
   failure has the local System ID and also has a higher Sequence Number

Li & Atkinson              Expires in 6 months               [Page 3]

Internet Draft            IS-IS Authentication              20 June 2001

   than  the IS-IS process has.  In this event, the IS-IS process SHOULD
   increase its own LSP Sequence Number  accordingly  and  re-flood  the
   LSPs.  However, as this scenario could also be triggered by an active
   attack by an adversary, it is recommended that a counter also be kept
   on this case to mitigate the risk from such an active attack.

3. Security Considerations

        This  document  enhances  the  security  of  the  IS-IS  routing
   protocol.  Because a routing protocol contains information that  need
   not   be  kept  secret,  privacy  is  not  a  requirement.   However,
   authentication of the messages within the protocol is of interest, to
   reduce  the  risk  of an adversary compromising the routing system by
   deliberately injecting false information into the routing system.

        The technology  in  this  document  provides  an  authentication
   mechanism for IS-IS.  The mechanism described here is not perfect and
   does not need to be perfect.  Instead, this  mechanism  represents  a
   significant  increase  in the work function of an adversary attacking
   the  IS-IS  protocol,  while  not   causing   undue   implementation,
   deployment, or operational complexity.

        This  mechanism  does  not  prevent replay attacks, however such
   attacks would trigger existing mechanisms in the IS-IS protocol  that
   would  effectively reject old information.  Denial of service attacks
   are not generally preventable in a useful networking protocol [4].

        Changes  to  the   authentication   mechanism   described   here
   (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were
   considered  at  some  length,  but  ultimately  were  rejected.   The
   mechanism  here  was  already widely implemented in 1999.  As of this
   writing, this mechanism is fairly widely deployed  within  the  users
   interested in cryptographic authentication of IS-IS.  The improvement
   provided by the proposed revised mechanism was not  large  enough  to
   justify  the  change,  given  the installed base and lack of operator
   interest in deploying the proposed revised mechanism.

        If and when a key  management  protocol  appears  that  is  both
   widely  implemented  and  easily deployed to secure routing protocols
   such as IS-IS, a different authentication mechanism that is  designed
   for use with that key management schema could be added if desired.

        If  a stronger authentication were believed to be required, then
   the use of a full digital signature [5] would  be  an  approach  that
   should  be seriously considered.  It was rejected for this purpose at
   this time because the computational burden of full digital signatures

Li & Atkinson              Expires in 6 months               [Page 4]

Internet Draft            IS-IS Authentication              20 June 2001

   is  believed  to  be much higher than is reasonable given the current
   threat environment in operational commercial networks.

ACKNOWLEDGMENTS

        The author would like  to  thank  (in  alphabetical  order)  Ran
   Atkinson,  Dave  Katz, Steven Luong, Tony Pryzygienda, Nai-Ming Shen,
   and Henk Smit for their comments and suggestions on this document.

REFERENCES

   [1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message
   Authentication", RFC-2104, February 1997

   [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing
   Exchange Protocol for use in Conjunction with the Protocol for Providing
   the Connectionless-mode Network Service (ISO 8473)", International Standard
   10589 [Also republished as RFC 1142].

   [3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
   environments", RFC-1195, December 1990.

   [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level
   Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

   [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures",
   RFC-2154, June 1997.

Author's Address

   Tony Li
   Procket Networks
   1100 Cadillac Ct.
   Milpitas, California
   95035  USA

   Email: [email-masked]
   Phone: +1 (408) 635-7903

   RJ Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   95051  USA

   Email: [email-masked]
   Phone: +1 (408) 579-2800

Li & Atkinson              Expires in 6 months               [Page 5]

Internet Draft            IS-IS Authentication              20 June 2001

Li & Atkinson              Expires in 6 months               [Page 6]

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Alex Zinin <[email-masked]>
Date: Thu, 28 Jun 2001 15:01:55 -0700

After some discussion with tli, I quickly drafted a small
document (attached) that addresses some nasty replay attacks not
covered by the HMAC doc. The intention is to see if people
interested in ISIS authentication care about this stuff
at all. If there's enough interest, I'll beautify the text
and we can make it a separate WG item.

Another point for discussion---it may be a good idea to say
that the implementations must put the Auth TLV in the beginning
of the packet. This way we can drop attacker's packets and
authenticate valid ones faster (we don't have to parse the whole
thing). This, of course, will work only if the current
implementations already do so, which I'm not 100% sure about,
so more clue is welcome.

Cheers,

-- 
Alex Zinin

---

From: Alex Zinin <[email-masked]>
Date: Thu, 28 Jun 2001 15:52:09 -0700

Hannes,

 Thanks for the comment.

 Except for the savings on the TLV header, what would
 be the benefit? On the other hand, having a new TLV
 that is "covered" by the HMAC digest provides a nice
 transition behavior, i.e., those who don't know about
 it, just ignore it...

 BTW, there's a mistake in my draft---the Length field
 should be 4 bytes, not 5 :)

-- 
Alex Zinin

Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote:

> alex,

> couldn't we use a different authentication subtype
> rather than a new TLV ?

> hmac-md5 uses id 54 so maybe 55 ?

> frame format would be 5 bytes of cryptograhic sequence #
> plus 16 bytes of MD5 hash. TLV [10] length is always 22.

> /hannes

> On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote:
> | 
> | After some discussion with tli, I quickly drafted a small
> | document (attached) that addresses some nasty replay attacks not
> | covered by the HMAC doc. The intention is to see if people
> | interested in ISIS authentication care about this stuff
> | at all. If there's enough interest, I'll beautify the text
> | and we can make it a separate WG item.
> | 
> | Another point for discussion---it may be a good idea to say
> | that the implementations must put the Auth TLV in the beginning
> | of the packet. This way we can drop attacker's packets and
> | authenticate valid ones faster (we don't have to parse the whole
> | thing). This, of course, will work only if the current
> | implementations already do so, which I'm not 100% sure about,
> | so more clue is welcome.
> | 
> | Cheers,
> | 
> | -- 
> | Alex Zinin
> | 
> | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:
> | 
> | 
| >> Folks,
> | 
| >> It's equally been forever on this draft as well, but we WOULD appreciate it
| >> if you could look it over again.  It's been submitted as a revised ID.  If
| >> we could get comments in by the end of next week, please.  Assuming that
| >> there are no objections, we will push this forward to Informational.
> | 
| >> Ran & Tony
> | 
> | 
> | 
> | 
> | 
> | 
> | Network Working Group                                         Alex Zinin
> | Internet Draft                                             Nexsi Systems
> | Expiration Date: December 2001                                 June 2001
> | File name: draft-ietf-isis-auth-anti-replay-00.txt
> | 
> | 
> |                   Protecting ISIS from replay attacks
> | 
> |                 draft-ietf-isis-auth-anti-replay-00.txt
> | 
> | 
> | Status of this Memo
> | 
> |    This document is an Internet-Draft and is in full conformance with
> |    all provisions of Section 10 of RFC2026.
> | 
> |    Internet Drafts are working documents of the Internet Engineering
> |    Task Force (IETF), its Areas, and its Working Groups. Note that other
> |    groups may also distribute working documents as Internet Drafts.
> | 
> |    Internet Drafts are draft documents valid for a maximum of six
> |    months. Internet Drafts may be updated, replaced, or obsoleted by
> |    other documents at any time. It is not appropriate to use Internet
> |    Drafts as reference material or to cite them other than as a "working
> |    draft" or "work in progress".
> | 
> |    The list of current Internet-Drafts can be accessed at
> |    http://www.ietf.org/ietf/1id-abstracts.txt
> | 
> |    The list of Internet-Draft Shadow Directories can be accessed at
> |    http://www.ietf.org/shadow.html.
> | 
> | 
> | Abstract
> |    This document describes an additional mechanism for ISIS
> |    cryptographic authentication that protects networks running ISIS from
> |    simple packet replay attacks.
> | 
> | 1 Motivation
> | 
> |    The cryptographic authentication mechanism for [ISIS], described in
> |    [HMAC] provides basic authentication functionality sufficient for the
> |    majority of situations. However, this mechanism does not protect ISIS
> |    networks from the replay attacks that can be performed by the
> |    attacker if it has direct access to a broadcast segment running ISIS.
> | 
> |    Because the mechanism described in [HMAC] does not include the notion
> |    of "cryptographic sequence number", an attacker can easily replay
> | 
> | 
> | 
> | Zinin                                                           [Page 1]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |    recorded ISIS packets.
> | 
> |    Examples of these attacks include replaying an empty (listing no
> |    neighbor IS) IIH packets and thus causing routers on the segment to
> |    destroy the adjacencies with the router under attack, replaying CSNP
> |    packets and thus artifically attracting ISIS traffic (LSPs) to the
> |    segment's DIS, and so on. When used periodically, these attacks can
> |    cause global instability in an ISIS domain.
> | 
> |    This document defines a simple mechanism, similar to the one used in
> |    the OSPF protocol, to protect an ISIS network from the replay attacks
> |    by introducing cryptographic sequence number into ISIS packets. The
> |    method is compatible with the exsiting implementations of [HMAC].
> |    This document does not provide a solution for replay attacks based on
> |    the cryptographic sequence number roll-over. The administrator is
> |    supposed to change the keys to prevent this type of attacks.
> | 
> | 2 Proposed Solution
> | 
> |    The cryptographic sequence number if introduced in ISIS packets in
> |    the form of a new TLV with the type code <TBD>. The length of the
> |    Value field in the TLV is 4 bytes (32 bits). The value of the Length
> |    field is 5.
> | 
> |    The value field of the TLV contains the cryptographic sequence
> |    number.
> | 
> |  2.1 Sending ISIS Packets with Cryptographic Sequence Number
> | 
> |    Implementations supporting the extensions described in this document
> |    should maintain the cryptographic sequence number counter on a per-
> |    interface basis. Implementations may use the up-time timer, or
> |    initialize the counter with a zero value and increment it after
> |    sending each packet on the interface. The cryptographic sequence
> |    number roll-over procedure is not defined in this document.
> | 
> |    When constructing an ISIS packet authenticated using [HMAC], the
> |    router may include the cryptographic sequence number TLV in it. If
> |    the TLV is included, it should be considered a part of the text for
> |    the digest calculation.
> | 
> |  2.3 Receiving ISIS Packets with Cryptographic Sequence Number
> | 
> |    ISIS implementations supporting described extensions should maintain
> |    the received cryptographic sequence number on a per-neighbor basis.
> | 
> |    When receiving authenticated ISIS packets, the router performs the
> |    following checks.
> | 
> | 
> | 
> | Zinin                                                           [Page 2]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |     1. If the cryptographic sequence number TLV is present in
> |        the received packet, compare the value found in the TLV
> |        with the value in the neighbor data structure. If the
> |        received value is less than the locally recorded one,
> |        the ISIS packet should be ignored. Otherwise, the router
> |        should perform the packet verification procedure as
> |        described in [HMAC] and update the neighbor data structure
> |        with the received crypo sequence number.
> | 
> |     2. If the ISIS packet is authenticated using [HMAC], does not
> |        contain the crypto sequence number TLV, and the router is
> |        configured to perform crypto sequence number verification
> |        on the receiving interface, the ISIS packet should be ignored.
> |        Otherwise (the router is not configured to perform this
> |        verification), the packet should be authenticated as
> |        described in [HMAC].
> | 
> | 3 Compatibility Issues
> | 
> |    Implementations not supporting described extensions will ignore the
> |    cryptographic sequence number TLV. Also, implementations supporting
> |    the new TLV will interoperate with implementation using [HMAC] only
> |    unless explicitly configured to perform sequence number verification,
> |    which is expected to be done when all routers on a segment support
> |    described mechanism.
> | 
> | 4 Security issues
> | 
> |    This document describes a mechanism that improves security of the
> |    ISIS protocol.
> | 
> | 5 Acknowledgements
> | 
> |    <TBD>
> | 
> | 6 References
> | 
> |    [ISIS] ISO, "Intermediate system to Intermediate system routeing
> |           information exchange protocol for use in conjunction with the
> |           Protocol for providing the Connectionless-mode Network Service
> |           (ISO 8473)," ISO/IEC 10589:1992.
> | 
> |    [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"
> |           Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.
> | 
> | 7 Authors' addresses
> | 
> |    Alex Zinin
> | 
> | 
> | 
> | Zinin                                                           [Page 3]
> | 
> | 
> | 
> | 
> | 
> | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
> | 
> | 
> |    Nexsi Systems
> |    1959 Concourse Drive
> |    San Jose, CA 95131
> |    [email-masked]
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | 
> | Zinin                                                           [Page 4]
> | 
> |

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 29 Jun 2001 00:29:37 +0200

alex,

/hannes

| > Folks,
| > It's equally been forever on this draft as well, but we WOULD appreciate it
| > if you could look it over again.  It's been submitted as a revised ID.  If
| > we could get comments in by the end of next week, please.  Assuming that
| > there are no objections, we will push this forward to Informational.
| > Ran & Tony

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 29 Jun 2001 08:28:40 +0200

Alex,

no practical ones, only for-clarity reasons -
just want to avoid to have authentication distributed over 3 TLVs.
[10,133,and your <TBD> TLV] -
motivation for that is that some greenfield-customers of mine
[=people new to the IS-IS protocol] kept asking about
the motivation behind TLV 133 ... 

however i do admit that having the crypto-seq-key in a
dedicated TLV does provide some migration-sexyness.

what could be done is to _proper_ structure [subTLVs]
your new <TBD> TLV in order to have _one_ extensible
general purpose authentication TLV, which potentially
can carry future, arbitrary, security related information
[pub-keys] etc ...

i'd volunteer for the draft if people find that interesting ....

/hannes

On Thu, Jun 28, 2001 at 03:52:09PM -0700, Alex Zinin wrote:
| 
| Hannes,
| 
|  Thanks for the comment.
| 
|  Except for the savings on the TLV header, what would
|  be the benefit? On the other hand, having a new TLV
|  that is "covered" by the HMAC digest provides a nice
|  transition behavior, i.e., those who don't know about
|  it, just ignore it...
| 
|  BTW, there's a mistake in my draft---the Length field
|  should be 4 bytes, not 5 :)
| 
| -- 
| Alex Zinin
| 
| Thursday, June 28, 2001, 3:29:37 PM, Hannes Gredler wrote:
| 
| > alex,
| 
| > couldn't we use a different authentication subtype
| > rather than a new TLV ?
| 
| > hmac-md5 uses id 54 so maybe 55 ?
| 
| > frame format would be 5 bytes of cryptograhic sequence #
| > plus 16 bytes of MD5 hash. TLV [10] length is always 22.
| 
| > /hannes
| 
| 
| > On Thu, Jun 28, 2001 at 03:01:55PM -0700, Alex Zinin wrote:
| > | 
| > | After some discussion with tli, I quickly drafted a small
| > | document (attached) that addresses some nasty replay attacks not
| > | covered by the HMAC doc. The intention is to see if people
| > | interested in ISIS authentication care about this stuff
| > | at all. If there's enough interest, I'll beautify the text
| > | and we can make it a separate WG item.
| > | 
| > | Another point for discussion---it may be a good idea to say
| > | that the implementations must put the Auth TLV in the beginning
| > | of the packet. This way we can drop attacker's packets and
| > | authenticate valid ones faster (we don't have to parse the whole
| > | thing). This, of course, will work only if the current
| > | implementations already do so, which I'm not 100% sure about,
| > | so more clue is welcome.
| > | 
| > | Cheers,
| > | 
| > | -- 
| > | Alex Zinin
| > | 
| > | Wednesday, June 27, 2001, 1:07:56 PM, Tony Li wrote:
| > | 
| > | 
| | >> Folks,
| > | 
| | >> It's equally been forever on this draft as well, but we WOULD appreciate it
| | >> if you could look it over again.  It's been submitted as a revised ID.  If
| | >> we could get comments in by the end of next week, please.  Assuming that
| | >> there are no objections, we will push this forward to Informational.
| > | 
| | >> Ran & Tony
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | Network Working Group                                         Alex Zinin
| > | Internet Draft                                             Nexsi Systems
| > | Expiration Date: December 2001                                 June 2001
| > | File name: draft-ietf-isis-auth-anti-replay-00.txt
| > | 
| > | 
| > |                   Protecting ISIS from replay attacks
| > | 
| > |                 draft-ietf-isis-auth-anti-replay-00.txt
| > | 
| > | 
| > | Status of this Memo
| > | 
| > |    This document is an Internet-Draft and is in full conformance with
| > |    all provisions of Section 10 of RFC2026.
| > | 
| > |    Internet Drafts are working documents of the Internet Engineering
| > |    Task Force (IETF), its Areas, and its Working Groups. Note that other
| > |    groups may also distribute working documents as Internet Drafts.
| > | 
| > |    Internet Drafts are draft documents valid for a maximum of six
| > |    months. Internet Drafts may be updated, replaced, or obsoleted by
| > |    other documents at any time. It is not appropriate to use Internet
| > |    Drafts as reference material or to cite them other than as a "working
| > |    draft" or "work in progress".
| > | 
| > |    The list of current Internet-Drafts can be accessed at
| > |    http://www.ietf.org/ietf/1id-abstracts.txt
| > | 
| > |    The list of Internet-Draft Shadow Directories can be accessed at
| > |    http://www.ietf.org/shadow.html.
| > | 
| > | 
| > | Abstract
| > |    This document describes an additional mechanism for ISIS
| > |    cryptographic authentication that protects networks running ISIS from
| > |    simple packet replay attacks.
| > | 
| > | 1 Motivation
| > | 
| > |    The cryptographic authentication mechanism for [ISIS], described in
| > |    [HMAC] provides basic authentication functionality sufficient for the
| > |    majority of situations. However, this mechanism does not protect ISIS
| > |    networks from the replay attacks that can be performed by the
| > |    attacker if it has direct access to a broadcast segment running ISIS.
| > | 
| > |    Because the mechanism described in [HMAC] does not include the notion
| > |    of "cryptographic sequence number", an attacker can easily replay
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 1]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |    recorded ISIS packets.
| > | 
| > |    Examples of these attacks include replaying an empty (listing no
| > |    neighbor IS) IIH packets and thus causing routers on the segment to
| > |    destroy the adjacencies with the router under attack, replaying CSNP
| > |    packets and thus artifically attracting ISIS traffic (LSPs) to the
| > |    segment's DIS, and so on. When used periodically, these attacks can
| > |    cause global instability in an ISIS domain.
| > | 
| > |    This document defines a simple mechanism, similar to the one used in
| > |    the OSPF protocol, to protect an ISIS network from the replay attacks
| > |    by introducing cryptographic sequence number into ISIS packets. The
| > |    method is compatible with the exsiting implementations of [HMAC].
| > |    This document does not provide a solution for replay attacks based on
| > |    the cryptographic sequence number roll-over. The administrator is
| > |    supposed to change the keys to prevent this type of attacks.
| > | 
| > | 2 Proposed Solution
| > | 
| > |    The cryptographic sequence number if introduced in ISIS packets in
| > |    the form of a new TLV with the type code <TBD>. The length of the
| > |    Value field in the TLV is 4 bytes (32 bits). The value of the Length
| > |    field is 5.
| > | 
| > |    The value field of the TLV contains the cryptographic sequence
| > |    number.
| > | 
| > |  2.1 Sending ISIS Packets with Cryptographic Sequence Number
| > | 
| > |    Implementations supporting the extensions described in this document
| > |    should maintain the cryptographic sequence number counter on a per-
| > |    interface basis. Implementations may use the up-time timer, or
| > |    initialize the counter with a zero value and increment it after
| > |    sending each packet on the interface. The cryptographic sequence
| > |    number roll-over procedure is not defined in this document.
| > | 
| > |    When constructing an ISIS packet authenticated using [HMAC], the
| > |    router may include the cryptographic sequence number TLV in it. If
| > |    the TLV is included, it should be considered a part of the text for
| > |    the digest calculation.
| > | 
| > |  2.3 Receiving ISIS Packets with Cryptographic Sequence Number
| > | 
| > |    ISIS implementations supporting described extensions should maintain
| > |    the received cryptographic sequence number on a per-neighbor basis.
| > | 
| > |    When receiving authenticated ISIS packets, the router performs the
| > |    following checks.
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 2]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |     1. If the cryptographic sequence number TLV is present in
| > |        the received packet, compare the value found in the TLV
| > |        with the value in the neighbor data structure. If the
| > |        received value is less than the locally recorded one,
| > |        the ISIS packet should be ignored. Otherwise, the router
| > |        should perform the packet verification procedure as
| > |        described in [HMAC] and update the neighbor data structure
| > |        with the received crypo sequence number.
| > | 
| > |     2. If the ISIS packet is authenticated using [HMAC], does not
| > |        contain the crypto sequence number TLV, and the router is
| > |        configured to perform crypto sequence number verification
| > |        on the receiving interface, the ISIS packet should be ignored.
| > |        Otherwise (the router is not configured to perform this
| > |        verification), the packet should be authenticated as
| > |        described in [HMAC].
| > | 
| > | 3 Compatibility Issues
| > | 
| > |    Implementations not supporting described extensions will ignore the
| > |    cryptographic sequence number TLV. Also, implementations supporting
| > |    the new TLV will interoperate with implementation using [HMAC] only
| > |    unless explicitly configured to perform sequence number verification,
| > |    which is expected to be done when all routers on a segment support
| > |    described mechanism.
| > | 
| > | 4 Security issues
| > | 
| > |    This document describes a mechanism that improves security of the
| > |    ISIS protocol.
| > | 
| > | 5 Acknowledgements
| > | 
| > |    <TBD>
| > | 
| > | 6 References
| > | 
| > |    [ISIS] ISO, "Intermediate system to Intermediate system routeing
| > |           information exchange protocol for use in conjunction with the
| > |           Protocol for providing the Connectionless-mode Network Service
| > |           (ISO 8473)," ISO/IEC 10589:1992.
| > | 
| > |    [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication"
| > |           Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt.
| > | 
| > | 7 Authors' addresses
| > | 
| > |    Alex Zinin
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 3]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | INTERNET DRAFT     Protecting ISIS from replay attacks         June 2001
| > | 
| > | 
| > |    Nexsi Systems
| > |    1959 Concourse Drive
| > |    San Jose, CA 95131
| > |    [email-masked]
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | 
| > | Zinin                                                           [Page 4]
| > | 
| > | 
| 
| 
| _______________________________________________
| Isis-wg mailing list  -  [email-masked]
| http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 29 Jun 2001 09:20:07 +0200 (MEST)

> and we can make it a separate WG item.

hmm , wouldn't that be rather something that we'd stick together
with key id into the HMAC TLV ? I'm getting just so litle concerned
about the proliferation of arbitrary TLVs floating around. It's 
not even that much the number space but you have to define the 
correlation of all those pieces of junk (eeeh, sorry, information)
to each other. What you do if HMAC is not around and you have 
this crypto sequence number in the packet? And what if you have
HMAC but not the crypto. The answer is always 'Obviously you do X'
but if not spelled out in some clear specs what X must be , 
multiple implementors
arrive to different 'X' solutions and interesting effects will
occur. This group is here to prevent those interesting effects 
from happening.

Technically, I glanced over your draft and it seems to me that what you 
trying to field is a 'nonce'. I've been told nonces are pretty
useless unless you actually negotiate them during adjacency
bring-up since otherwise somebody can record a session and
replay it with the recorded nonces. So not much protection you give. 
As well, think about implementations that process hellos before
they get to CSNP so they reorder internally. That makes nonces
hard since those implementations could drop packets arbitrarily.
Nothing anywhere seems to say that you have to process packets in the 
sequence you take them of the wire. BGP is simpler in this respect.

Rja may want to chime
in here but otherwise I'd strongly suggest to consult a security
expert who's done that before. I did that mechanism (key 
negotiation, nonce, even source authentication) in all gory
details once and it has more to it than meets the eye. Key id 
was kind of too obvious to let it pass I thought but getting 
into nonces will take it sweet time to get right.  Having said
that, I have nothing against a draft that specifies TLV
as we have today, key id+HMAC variation of the TLV and later version/RFC
with key id + nonce + HMAC variation of the TLV. They'll be all
backwards compatible since you can differentiate them on the 
length of the TLV. The only sentence needed is "implementation
MUST ignore HMAC TLV with unexpected length". Of course per 
interface knob is needed to say "send-plain-HMAC", "send-keyid-HMAC",
"send-keyid-nonce-HMAC". I don't have any particular 
preference, I'm just trying to keep the discussion 
technically sound and speak out trade-offs involved.

> implementations already do so, which I'm not 100% sure about,

parsing the TLV headers until you arrive to the HMAC tlv is 
very cheap (withough looking @ the content until you hit HMAC).
If you enforce that Auth TLV must be first, then you 
have to say what the implemenation supposed to do when it's not.
Dropping the packet
is kind of too harsh so you probably want "it SHOULD put it in 
the beginning and if it's somewhere else, accept anyway". 

Paul Koning taught me  something about protocol
design: If you want something in a packet but then you accept it
anyway if it's not that way, it's a waste of time even specifying
it. Occams razor or
in words of Goethe "In der Beschraenkung zeigt sich der Meister" or
in words of Henk "be liberal in what you accept" ;-)

	-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 29 Jun 2001 00:07:19 -0700

> i'd volunteer for the draft if people find that interesting ....

not a bad idea me thinks. That could take care of the key-id, nonce
and other stuff in a cleaner way that all other ways I've seen so far.
Why wouldn't we attach that stuff in 133 right after the HMAC e.g. ?

    -- tony

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 00:46:31 -0700

Hannes,

> the motivation behind TLV 133 ... 

Well, since 133 is not used anyway, we have only two,
which should be ok :)

> dedicated TLV does provide some migration-sexyness.

Yes, and I think this is pretty valuable.

> can carry future, arbitrary, security related information

Hmmm... No problem subdividing... Would save the T-space,
I guess... Kind of having hard time imagining people actually
putting anything there considering the current state of
interest in security, though :))

> i'd volunteer for the draft if people find that interesting ....

Let's see what people say and coordinate then.

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 01:13:19 -0700

That's a long one :)
See below, pls.

> with key id into the HMAC TLV ?

Correct me if I'm wrong, but HMAC is not trying to send the Key ID,
just the digest. I specifically wanted to introduce as less changes
to the HMAC mechanism (since it is already deployed, I take it)
as possible.

> I'm getting just so litle concerned

That's why I said this is a quick _draft_ and I'll address this if
there's enough interest.

> trying to field is a 'nonce'.

Exactly, but not a random one as other protos do...

> I've been told nonces are pretty

Yes and no. Yes, meaning that the attacker can replay the session.
No meaning that protection is still there. We use the same mechanism
in OSPF. The assumption is that the key is changed on the segment
(in the domain) before the CryproSeqNum rolls over.

> sequence you take them of the wire. BGP is simpler in this respect.

I agree here. Note however, that implementations usually do the
authentication check as a part of the common sanity check and _then_
diverge the processing paths. So, this is addressible.

> into nonces will take it sweet time to get right.

Hmmm... I think it's doable. The scheme works for OSPF already.

>  Having said

I guess another consideration here is how much HMAC is deployed
and whether the length check is there or not. If it's not there,
and it's relatively widely deployed, we better off using a new TLV.

> very cheap (withough looking @ the content until you hit HMAC).

One could envision an attacker doing a DOS-type of attack sending
invalid, MTU-long IIHs, containing bogus TLVs and putting the HMAC
one the last in set. Couple of loads instead of hundreds sounds like
a difference. Now recall jumbos and subsecond hellos...
I'm not saying this will save us from it, but it just seems better
to me.

> the beginning and if it's somewhere else, accept anyway".

No, this would defeat the whole thing.

> it.

Exactly.

> Occams razor or

Well, I guess protocol security itself is kind of an exception from
this rule :)

IMHO if implementations do put 10 in some order today, we should
take advantage of this.

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 01:18:31 -0700

Putting the key-id sounds indeed as a _real_ reason for sub-TLVs.

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 01:29:29 -0700

> and it's relatively widely deployed, we better off using a new TLV.

Commenting myself. I would expect the length check to be there
as a part of normal well-known TLV processing, so probably this
is not a problem. But using 133 with Sub-TLVs sounds indeed better
to me.

Alex.

---

From: David Hudek <[email-masked]>
Date: Fri, 29 Jun 2001 13:21:58 -0700

> diverge the processing paths. So, this is addressible.

This might make things more difficult for implementations
that use a separate high priority/urgent data path for
received hellos, taking a divergent processing path _before_
any common protocol sanity checking. Of course, there are alternate 
methods that could be employed, but it raises a question...

Out of curiosity, what would be the security effects of slightly
loosening the condition that a received message must have a higher
crypto seq num than the last recorded crypto seq num from the nbr,
to instead say that a received message must have a crypto seq num
no less than N behind the last recorded crypto seq num from the nbr
(for small N) ?  Instead of monotonically increasing received seq 
numbers, there would then be a small window of lagging but still valid 
numbers which slides up. On the one hand, it would permit a small amount 
of internal reordering (e.g., hellos could leapfrog up a bit), 
but on the other hand it would allow a malicious entity to replay 
some of the currently last N messages. How much of 
a lag would there need to be to cause a serious security risk? 

Side note: after rereading the draft, 
I have another question... in section 2.3 step 1, it says that
the received crypto seq number cannot be less than the last
recorded one... assuming that seq nums should be increasing per sec 2.1,
should that say instead that it cannot be less than or equal to
the recorded one (i.e., must be greater)? 
Also, if so, then sec 2.1 should probably say on sending
to init at 1 or greater instead of allowing 0 since the increment
is done after sending (assuming the receiving side will init the 
recorded value to 0).

Thanks,
dave h

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Jun 2001 12:45:51 -0400

>(in the domain) before the CryproSeqNum rolls over.

        There are known issues with the OSPF and RIP use of the 
sequence number.  Vernon Schryver is normally happy to discuss 
at some length if asked.  As it happens, the deployment was 
too widespread for it to be realistic to change either of those specs 
-- at the point that issue entered the public literature.

Ran

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 11:00:04 -0700

David,

> methods that could be employed, but it raises a question...

Good point, see below.

> a lag would there need to be to cause a serious security risk?

Well... this would give a much bigger window to the attacker.

I think the right way to address the problem of convergent processing
paths is maintaining separate CSNs on the sending and the receiving
sides so that CSNs, SNPs and LSPs have different contexts. In fact, since
ISIS is authenticating LSPs, one would probably want to have separate
CSNs for LSPs anyway. So we can just make it generalized enough and
say the three groups have separate sets.

> the recorded one (i.e., must be greater)?

The reason for strict "not less" is to allow implementations that
use a local timer as the CSN and send multiple packets within a sec.

Thanks,

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 11:06:28 -0700

Ran,

 Thanks for the info, I'll get in touch with Vernon.
 Meanwhile, do you have any pointers?

-- 
Alex Zinin

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 15:16:01 -0700

> say the three groups have separate sets.

Thinking more about this... I guess we can go without CSNs in LSPs,
as the LSP's own SN should be enough in most cases (except for
the purge case, which is described in HMAC). So, we need only
two CSN groups---IIH & SNPs.

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 29 Jun 2001 20:06:09 -0700

Folks,

 So, we had a discussion with Vernon (RJ was CC'ed, so
 he'll probably step in if I do not reflect the discussion
 correctly).

 The SeqNum problems discussed are as follows:

   1. What happens when the SeqNum rolls back to 0.
   2. What happens when the router restarts.
   
 I share these concerns completely.
 
 They way I suggest these problems to be addressed is
 as follows. (I belive Jerome Etienne has a paper on a similar
 mechanism for OSPF somewhere.)

   1. SeqNum roll back does not seem to be a problem to me,
      see item 4 below.

   2. In the new TLV, introduce the generation ID (16 or 32 bits).

   3. The implementations guarantee that the generation ID is
      incremented with each reboot using one of multiple methods,
      e.g., reading, incrementing and writing it back to nvram
      on each boot, or using seconds since somewhen, or a calendar
      clock, whatever is better suited for a specific system.

   4. The CSN is incremented after each packet. If a system sends
      10 packs per sec, 32-bit space will give us more than 10
      years of a key lifetime. We may want to increase it though,
      if we seriously consider subsecond hellos.

   5. The receiving side checks that the CSN in the packet is
      _greater_ than the locally stored value.

 Vernon did not seem to like the scheme, because of the possible
 issues with NVRAM, and calendar clock...

 I believe the scheme works. The NVRAM/flash/disk/floppy/tape/punch-card
 portion should work, since the write is happening once per reboot and
 does not depend on the packet sending frequency. In fact I believe this
 is an implementation issue and the doc should only hint on this, but
 definitely not specify.

 If anyone believes there are flaws, please speak up.

 Cheers,
 
Alex.

---

From: David Hudek <[email-masked]>
Date: Sat, 30 Jun 2001 11:59:32 -0700

> two CSN groups---IIH & SNPs.

Sounds good. Allows implementations to easily reorder
types of messages if desired (e.g., high priority hellos)

-------------------------------------------------------------------
I had another question, but upon reading my email this morning,
I see that it's already been addressed :-)
(problem with restarting after being up for a while... 
after restart you are using small seq num but BadGuy replays 
one of your previous high seq num to your peer... so peer stops 
listening to you until/unless your seq num increments up to the
old value)

I'm definitely NOT a security expert, but since there
were some drawbacks mentioned for the proposed scheme
(issues with NVRAM, and calendar clock),
I'm wondering what would be the drawbacks of taking a page
from the LSP seq num handling and just putting in a mechanism
for an entity to bump up their seq num state if they discover a
prior incarnation with higher state floating about. 

They could discover that if the crypto data in a hello 
included not only your crypto state (seqNum, or genId + seqNum)
for the message in question, but also your current view of your 
neighbor's state for each category (IIH, SNP). 

If upon examining your neighbor's hello, you discovered
that they had been fooled, you could set your seq number
state appropriately (e.g., set genId/seqNum higher) and so recover.
To handle the case of both sides under attack at the same time, 
I suppose the procedure would have to change to have you conditionally 
trust the neighbor's view of yourself even if their own seq num is 
too small to trust the rest of the message (assuming it passes the
hmac test)... only trust and act upon it if the number is greater 
than your current value, so you only ratchet up (never reduce) 
crypto state. 

As long as both sides only ratchet up their crypto state, 
naively it would appear to be OK for such trust (don't at first 
see how a BadGuy could exploit the conditional trust of the neighbor's 
view of your seq num... even if they replayed an older one with smaller
values you wouldn't set your state lower).

There may be horrible security flaws in this :-),
but it does seem a little simpler and more automatic,
without any nvram, calendar clock, etc. issues.
You can start off with 0 state and recover to
acceptable state after a hello from your peer.
Might be worth discussing?

Actually, I just thought of one possible bad scenario, but
it seems sort of far-out?... if a BadGuy had a large
history of your prior messages (you had been up a long time), 
then they could incrementally fool your neighbor... replay to 
set seq num a bit higher than you, then you recover, then they
replay a different one to set yet a bit higher, then you recover, etc.
You could recover with a relatively large extra jump to reduce this,
I suppose, but then you'll start using up the space faster.
If the space is large enough (genID+seqNum) then this
might not be an issue?

thanks,
dave h

---

From: David Hudek <[email-masked]>
Date: Sat, 30 Jun 2001 15:15:48 -0700

Quick comment on a possible implication of the hello text...

>    IS-IS HELLO PDUs SHALL use the  Link  Level
>    not disabled. 

This would seem to imply that if padding is not disabled,
then if you want to interoperate you must
pad every hello, which would appear to be a change to
the Point-to-point hello procedure in 10589
(where it says to only pad the first IIH hello).
Are the "dominant implementations" padding all the
p2p hellos anyway? 

Thanks,
dave h

---

From: steve luong <[email-masked]>
Date: Sat, 30 Jun 2001 12:20:32 -0700

No, it does not imply that. That sentence does not change the decision to pad or
not to pad the IIH
in anyway. It tells you the sequence of what to do first. The sequence is you
pad the IIH first (if the IIH is supposed to be padded), then do the MD5
calculation over the entire PDU.