Subject: [anonsec] charter comments

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 14:42:20 2004

Better-Than-Nothing Security WG (btns)
Draft Charter
v1.0
Nov. 18, 2004

Interim Chair: Joe Touch <[email-masked]>

Mailing List info. and preliminary Internet Drafts:
http://www.postel.org/anonsec

DESCRIPTION:

Current Internet Protocol security (IPsec) protocol suite presents
somewhat of an all-or-nothing alternative; existing protocols provide
protection from a wide array of possible threats,

>how about "attacks" vs.  "threats," or maybe say "in a wide range of 
>threat environments"

but are sometimes
not deployed because of the need for cumbersome management key
infrastructure or complex configuration.

>what configuration issues are you alluding to? most all of the 
>discussion has been about authentication. is the issue here the 
>config info needed to support authentication, or is there more?

  This proposed working group
will develop extensions to existing IPsec protocol suite to support
relaxed variants that reduce their need for pre-shared keys and/or key
management infrastructure. These relaxed variants provide weaker
security guarantees than their conventional counterparts, but should
be sufficient for use in limited environments, e.g., to protect
against off-path attacks but not man-in-the-middle, or to protect
connections without regard for authoritative identification of
communicating parties. The goal of these relaxed variants is to enable
and encourage the use of network security where it has been difficult
to deploy - notably, to enable simpler, more rapid deployment. This
work should not preclude the binding of security thus provided with
security at other layers.

>the reference to binding here is vague

(the WG will focus on the IPsec protocol suite, possibly including
IPsec and/or IKE upon its instantiation;

>do you mean upon instantiation of the WG, vs. the instantiation of IKE?

  after completing work on
the IPsec suite, the WG may seek rechartering to consider other Internet
security protocols)

** QUESTION: is "IPsec protocol suite" the appropriate term?

>I think not. do you plan to "profile" AH or ESP, now that the high 
>performance aspects of the original proposal have been deleted?

The WG has the following specific goals over three IETF meetings:
     a) characterize a reasonable set of threat models with
        relaxed assumptions suitable for infrastructure-free
        and/or high-performance use

>delete the reference to high performance

     b) identify existing IPsec protocol suite standards track
        protocols for extension and determine whether configuration
        (BCP) or extension (standards-track) is appropriate for each

>this is a confusing bullet., as currently worded. first, the only 
>protocol from the Ipsec suite that seems to be on the table is IKE. 
>also, do you mean to say if the recommendation is a configuration 
>issue then you issue a BCP, and if you "extend" the protocol that 
>you envision a standards track RFC. we've talked a lot about 
>"profiling" yet that term does not appear here; why substitute 
>"extension" for "profile?"

     c) document protocol configurations and/or extensions for
        infrastructure-free use

>  if you delete "b" above and just have this as the second bullet, it 
>would seem clearer, and maybe you could put the BCP vs. standards 
>track text at the end of this bullet.

The current ANONSEC ID will serve as the initial issues (requirements)
document. Items (a) and (b) above comprise the framework document. Each
protocol specification modified as per (c) will comprise a
separate WG contribution. One or more of these contributions will be
published as BCPs (requirements, framework, and configurations not
requiring protocol variation) or standards-track documents (for
protocols requiring variations).

>given the scope discussion at the BOF, I'm not sure the cited I-D is 
>a good starting point. also, since the charter is just for IPsec, 
>and you said you would re-charter for other protocols, much of the 
>text immediately above does not seem appropriate anymore.

Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/anonsec/attachments/20041119/4b32fa3f/attachment.html

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 15:29:13 2004

<BOF HAT ON>

(I think I follow that your comments are indented more, not less)

Stephen Kent wrote:
...
>> discussion has been about authentication. is the issue here the config 
>> info needed to support authentication, or is there more?

I meant config to mean "seting up the preshared keys or the signed X.509 
certs", perhaps including more (perhaps; I don't know what else might be 
able to be automated).

...
>> the reference to binding here is vague

s/binding/channel binding/ ??

>> do you mean upon instantiation of the WG, vs. the instantiation of IKE?

Sorry - instantiation of the WG.

>> performance aspects of the original proposal have been deleted?

No, but there may be issues for IKE or IKE profiling, or issues for 
IPsec SAD/SPD. I didn't want to say IPsec (omits IKE) or just IKE. Is 
there a term that lets the WG figure out what needs fixing, rather than 
declaring it specifically in the charter, without doing the work now to 
figure out the fix?

>> delete the reference to high performance

Sorry - I thought I already had. Consider that omitted.

>> issue then you issue a BCP, and if you "extend" the protocol that you 
>> envision a standards track RFC. we've talked a lot about "profiling" 
>> yet that term does not appear here; why substitute "extension" for 
>> "profile?"

I thought others had mentioned issues with IPsec SAD/SPDs. This hints at 
that.

...
>> given the scope discussion at the BOF, I'm not sure the cited I-D is a 
>> good starting point. also, since the charter is just for IPsec, and 
>> you said you would re-charter for other protocols, much of the text 
>> immediately above does not seem appropriate anymore.

The I-D is the motivation of the issues, but needs revision to (a) focus 
on IPsec and (b) omit high-speed.

Agreed that the text above was more for the BOF than the WG. The first 
sentence need not be in the WG charter; it's a suggested starting point 
for one of the docs only. As to the rest, I agree it isn't germane to 
the WG's chartering anyway.

<hat off>

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/4845f80c/signature-0001.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 15:52:23 2004

Joe,

>IPsec SAD/SPD. I didn't want to say IPsec (omits IKE) or just IKE. 
>Is there a term that lets the WG figure out what needs fixing, 
>rather than declaring it specifically in the charter, without doing 
>the work now to figure out the fix?

IKE seems to be the only protocol you might want to profile. The 
SAD/SPD issues are not in a protocol spec, but the architecture spec. 
You could just refer to it that way.

>>>protocol from the Ipsec suite that seems to be on the table is 
>>>IKE. also, do you mean to say if the recommendation is a 
>>>configuration issue then you issue a BCP, and if you "extend" the 
>>>protocol that you envision a standards track RFC. we've talked a 
>>>lot about "profiling" yet that term does not appear here; why 
>>>substitute "extension" for "profile?"
>
>I thought others had mentioned issues with IPsec SAD/SPDs. This hints at that.

Others may have, but that still does not make the words clear here. 
As I suggested in my message, I think we're better off with "c," 
deleting "b."

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 16:07:24 2004

Stephen Kent wrote:
>> there a term that lets the WG figure out what needs fixing, rather 
>> than declaring it specifically in the charter, without doing the work 
>> now to figure out the fix?
> 
> 
> IKE seems to be the only protocol you might want to profile. The SAD/SPD 
> issues are not in a protocol spec, but the architecture spec. You could 
> just refer to it that way.

<BOF hat on>

AOK.

> Others may have, but that still does not make the words clear here. As I 
> suggested in my message, I think we're better off with "c," deleting "b."
> 
> Steve

Understood. I'll let others weigh in, FWIW, before incorporating mods, 
just to avoid creating shifting-sands.

<hat off>

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/3b471105/signature.bin

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri Nov 19 18:12:23 2004

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> Joe,
    >>>> I think not. do you plan to "profile" AH or ESP, now that the
    >>>> high performance aspects of the original proposal have been
    >>>> deleted?
    >>  No, but there may be issues for IKE or IKE profiling, or
    >> issues for IPsec SAD/SPD. I didn't want to say IPsec (omits
    >> IKE) or just IKE. Is there a term that lets the WG figure out
    >> what needs fixing, rather than declaring it specifically in the
    >> charter, without doing the work now to figure out the fix?

    Stephen> IKE seems to be the only protocol you might want to
    Stephen> profile. The SAD/SPD issues are not in a protocol spec,
    Stephen> but the architecture spec. You could just refer to it
    Stephen> that way.

Hi.  Speaking as an individual, I think I find Joe's original "IPsec
protocol suite," more clear than what you are suggesting.  I might
find your statements more clear if you suggested specific text.

I do agree that what Joe proposes is broader than what is necessary;
for example a profile of ESP would be in the scope of what he said.  I
don't think this scope is unreasonably broad and don't think it will
be abused.  If it is abused, I have high confidence that we can deal
with clarifying the scope when a problem happens.

--Sam

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 08:21:34 2004

>find your statements more clear if you suggested specific text.

How about referring explicitly to IKE and to the PAD and SPD, as 
changes to these may be required to accommodate the desired goals.

>with clarifying the scope when a problem happens.

Since the BOF attendees voted to not include optimizations to ESP or 
AH, then why include any references to protocols for which we have no 
clear need to make any changes?

Steve

Steve