Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational

From: "George, Wes" <[email-masked]>
Date: Wed, 3 Apr 2013 11:21:35 -0400

I've reviewed this draft before at Sam's request, so I don't have a lot of comments, but here are a few items I see in the most recent version in WGLC.

3.2 key expiration -- Might be useful to have a pointer to 6.2 where handling expiration faults is discussed in more detail. Also, would it be appropriate to discuss a config knob to more finely control expiration handling? I'm thinking of something that would allow a fail-open or fail-safe condition, where expiration generates a fairly insistent warning but instead of immediately tearing down that session, the implementation will maintain the session as long as it stays up, but if it goes down for some other reason (lost connectivity, etc.) it will not be permitted to re-establish until the expired key is addressed. I'm sure there are some security risks to this, but it might be a useful tradeoff for folks still getting the hang of managing key expiration.

5. Grouping peers - need to be able to ungroup a peer or peers without impacting routing - one of the problems with things like BGP Peer groups using a common MD5 password today is that if you need to change the password, you affect the entire peer group at once. The ability to override a group config with a peer-specific config as an extension of key rollover provides a lot of flexibility, such that it may be useful to make that an explicit requirement. This is discussed some in Section 7, but may need some companion text here.

6.1 - not sure I'd assume that proper procedures are in place to be followed. The overlap between "Router people" and "security people" is often limited, so I'm of the mind that some amount of specifics in terms of rules of thumb are useful, or at least discussing what if anything might be different in handling this provisioning step.
see also draft-ietf-sidr-rtr-keying's discussion of provisioning a router. Discussion on some of that in my review of that document. Thread here: http://www.ietf.org/mail-archive/web/sidr/current/msg05659.html

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gunter Van de Velde (gvandeve)
> Sent: Tuesday, April 02, 2013 5:11 AM
> To: [email-masked]
> Cc: Joel Halpern
> Subject: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to
> Informational
>
> Dear OPSEC WG,
>
> Please take some time to comment upon draft-ietf-karp-ops-model-05.
>
> Make take your comments direct to the authors and copy the KARP WG.
>
> The KARP working group is designing improvements to the cryptographic
> authentication of IETF routing protocols.  These improvements include
> improvements to how integrity functions are handled within each protocol
> as well as designing an automated key management solution.
>
> Kind Regards,
> G/ (OPSEC Co-chair)
>
> > From: Brian Weis <[email-masked]>
> > Subject: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational
> > Date: March 26, 2013 5:00:19 PM PDT
> > To: "[email-masked]" <[email-masked]>
> >
> > This begins a two week WG last call to determine if folks will support
> the chairs to submit
> >     <http://tools.ietf.org/html/draft-ietf-karp-ops-model-05>
> > to our AD for publication as an Informational RFC.
> >
> > Please send comments of support, or raising issues or concerns, to the
> WG email list by 5pm PDT on 9-April-2013.
> >
> > Thank you,
> > Joel M. Halpern
> > and Brian Weis
> > co-chairs
> > _______________________________________________
> > karp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/karp
>
> --
> Brian Weis
> Security Engineering, SRG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: [email-masked]
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 04 Apr 2013 18:08:12 -0400

Hi.
With regard to  your proposed key expiration  and peer ungrouping text,
I'd like to offer my support for the ideas but ask for additional
support from the WG.
Also, any opinions on what strength language we want there?
MAY/SHOULD/MUST/MUST (BUT We KNOW YOU WON't)?

I'm tending toward SHOULD personally.

With regard to 6.1. People are doing something with administrative
passwords.
It may be good or bad, but their security already depends on it.
Does opsec have some advice in this area we can reference?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Apr 2013 08:44:17 -0400

Hi.  I didn't see any last call comments besides Wes's comments.  I'd
also like to get some support for Wes's comments before folding them in.
As I've said I personally support but would prefer to see if we can
shake up more than one person saying "yes" at this stage.

chairs, would it make sense for me to try and prepare a draft next week
that hopefully can be sent on?

---

From: Brian Weis <[email-masked]>
Date: Wed, 10 Apr 2013 10:08:15 -0700

As chair, I'd like to see more declarations of support before progressing the document. I'll extend the end of last call until 4/16 in order to give others the chance to comment. Sam, why don't you hold off with a new draft until then.

Folks, the KARP work will be of little value if the operators can't deploy it. This document provides needed advice to operators on best practices for handling credentials and keys. Advice on use of the KARP key table specification is a significant part of the document. We do need to show consensus that it is the right advice. Please read and comment, or at least provide an indication of approval or disapproval.

Thanks,
Brian

---

From: William Atwood <[email-masked]>
Date: Wed, 10 Apr 2013 16:04:55 -0400

I support draft-ietf-karp-ops-model-05 as Informational.

I assume that the corrections that I suggested (off-line) to Sam and
Dacheng will be incorporated into a final version.

Wes's issue of key expiration makes sense to me, so I support it.

Wes' issue of grouping/ungrouping peers makes sense to me, so I support
it.  We have touched on one aspect of this issue (the scope of keys) in
draft-atwood-karp-akam-rp.

I have read the comment on Section 6.1 and the email that is cited.  I
agree that, for the kind of document that ops-model is intended to be
(i.e., targeted at a member of a routing working group who knows little
about security), no assumption should be made about "proper security
procedures being in place".  It is the fact that we know that they are
_not_ in place that is driving the entire KARP effort, after all.  I
therefore support inclusion of more text here.

  Bill

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Melinda Shore <[email-masked]>
Date: Wed, 10 Apr 2013 14:22:43 -0800

> shake up more than one person saying "yes" at this stage.

Here's a "yes."  I'm actually pretty good with section 6.1 -
in my experience the people managing and configuring routers
do have an appreciation for the sensitivity of router management
keys/passwords (this is not a particularly subtle issue or one
that requires specialist knowledge).  I'm not really in love with
section 3.1 (routers validating cryptographic parameters) but
I can live with it.

I think the document is in good shape and ready to move
forward.

Melinda

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Apr 2013 19:42:24 -0400

>>>>> "William" == William Atwood <[email-masked]> writes:

    William> I support draft-ietf-karp-ops-model-05 as Informational.  I
    William> assume that the corrections that I suggested (off-line) to
    William> Sam and Dacheng will be incorporated into a final version.

Yes, your comments and Wes's comments are what I have queued.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 15 Apr 2013 21:11:19 +0000

Dear Authors,

I happened to read this  document again after a long time and it's changed quite a bit and in the current form it's certainly  relevant for Routing operations folk. 
You touched upon scope of keys to, configuration using key tables, various key types being used (KARP scope) and handling faults. All are very useful.

First I would share my opinion on the suggestions asked for:

3.2 key expiration -- (my comments for new suggested text)

Though it's fair from operations perspective, obviously not good for security perspective. Probably situation with key roll over for RP's could improve with Key management protocols usage (with in built soft key rollover times etc..). In that spirit you can at best use a "MAY"

5. Grouping peers - 
Yes, useful and it's reasonable.

6.1 - 
Very important aspect and not aware of any opsec document which touches this aspect.

Other not so significant comments I have:
-----------------------------------------

1. Section 1 - Page 3

   "This document also gives recommendations for how management and
   operations.."
    s/operations/operational

2. Section 3.2
     - Currently text mainly focus on manual deployments.
     - Section 3.3 talks different aspect with KMPs not the rollover
     - Hence, this section may need to consider both manual keys and keys being populated by the KMP; 
       where KMP  (peer2peer or group) ensures keys are properly replenished before the old keys expiry.

3. Section 4 (last 3 paragraphs)
    - It's better if  the scope of the keys talked about differentiates for RPs and KMPs in separate sections.
      I am indicating this because, certificates and other form of authentication methods are not directly applicable to RPs, with in KARP scope.

4. Section 4.2 and 4.3
    - These are not directly applicable to RPs but critical for KMPs.
      If you can restructure section 4, it benefits immensely for the routing developers and operator community.

5. Section 6.2
   "Faults may interact with operational practice in at least two ways.
   First, security solutions may introduce faults.  For example if
   certificates expire in a PKI, previous adjacencies may no longer
   form.  Operational practice will require a way of repairing these
   errors.  This may end up being very similar to repairing other faults
   that can partition a network."

   Need to indicate this as KMP related issue rather than RP issue as far as KARP is concerned.

--
Uma C.