Subject: Re: framework draft v07 uploaded to IETF

From: "(Ram Gopal )" <[email-masked]>
Date: Mon, 4 Aug 2003 20:10:04 -0400

Hello Jamal,

Comments are inline.

> Your security "recommendations" do make certain assumptions, the most
> important being that CE<->FE is a unicast connection. With TLS you go
> further to make assumption of need for TCP. Now this may be 
> fine for FACT
> but it is not for Netlink2 (because we could be running 
> either as unicast
> or multicast). And you cant make "recommendations" if we 
> havent decided on
> the protocol - unless you can tell me how to run TLS using 
> multicast. This
> is why i called this a show stopper.

<RamG>
Couple of points 

1.We have not considered neither FACT nor Netlink2 nor Foo etc when documenting framework security section..
We have made it clear both in the document and also in the IETF vienna meeting that we have covered all options based
on the requirement document. 

We took the protocol and architecture requirement and against that we did threat analysis and came up with the recommendations.

Requirement document identified following protocol (and security) requirements that needs to be considered for 
as part of CE-FE communication.  
 
Reliability, 
No security, 
Integrity, 
Confidentiality, 
timeliness, 
replay protection etc.

Requirement didn't talk about unicast of multicast protocol as it falls in (solution space).

2.  We have taken approach to document IPsec and TLS as these are two common protocols that can be candidate, and 
satisfy all the security requirements between CE and FE.

3. Framework security section is neutral and doesn't recommend any protocol and its upto the administrator (or protocol
designer) to choose.

If one wants to use multicast, IPsec could be used with manual keying with no replay protection and no automatic rekeying 
for both confidentiality and integrity service.  Again this may be protocol choice...

<RamG>

> 
> So what i am asking for is objective text which encompases 
> both points of
> views. For example, no problem with IPSEC ESP being 
> "recommended" because
> that is fine for multicast as well - but it would make sense to see
> generic text which covers both uni and multicast in that section.
> [I have reservations about TLS but i am willing to ignore its 
> presence. I
> think it would be anti-progress (if such a word exists) on my 
> part to say
> in addition to TLS lets also "recommend" a security mechanism 
> that would
> work well only with multicast.]
> 

<RamG>

We have documented existing security protocol to make secure CE-FE communication. It is upto the protocol designer
to choose one depending upon the transport protocol.

<RamG>

> Maybe the chairs could invite someone else to write that text since we
> have been arguing about this for a long time - and i 
> sincerely think it is
> a showstopper. I dont think you are being intentionaly 
> difficult - i just
> think you are in one zone and i on another.

> 
> And btw, have we finally reached an agreement that we cant 
> run Forces over
> Ethernet directly? If no, what security mechanisms are you 
> proposing that
> cover both uni and multicast?
> 

<RamG>

Note in all other working groups based on the transport protocol security considerations are written.
Requirement document has not recommended and neither wg has selected whether the protocol is unicast or multicast.

Secondly, framework at the moment talks about FE-CE communication security and provided options that confirms to 
requirements document.

FYI with IPsec (refer RFC 2401), one can use with multicast for integrity and confidentiality with  
a compromise on rekeying and replay protection.  

<RamG>

Regards
Ramg

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 4 Aug 2003 20:25:02 -0700

Ram,

You clearly have semantics all over the document that indicate
unicast. Example:

-------
We recommend using ESP in transport mode for ForCES because message
confidentiality is required for ForCES and the communication between the
CE and FE is point-to-point.
-------

I dont think i should be nitpicking on the text because it is
a waste of time - We have had this struggle all along in the requirements
document as well between you, Hormuzd and myself.

The primary objective is to build a protocol that does FE<->CE
communication, not build a security mechanism then wrap it with a
protocol that does CE<->FE communication.

Since we dont know what the final protocol is going to be
please stop putting restrictions. Example your text below.

> a compromise on rekeying and replay protection.

What next? "oh, btw you cant use TLS because you use Multicast".
Maybe you'll point to the requirements and say why multicast is not
allowed. Perhaps something i missed during the requirements collection.

Whether you think it is right or not, multicast is very appealing
for Forces: Single CE, multiple FEs (point to multipoint); HA,
redundancy etc. Please do not impose any restrictions which will rule out
its use when we havent decided on the protocol.
BTW, your statement on IPSEC above is innacurate - and while that is
beside the point - it shows you are on one extreme.

You are making recomendations. The definition of the word is
pretty clear. You say TLS for example can "satisfy all requirements of
security" - YES, this is true provided you use a) unicast transport b)
which is TCP (any other thing working with TLS is obscure).

Lets have someone else - not you, not Hormuzd, not me (we are all
biased) - to write this text with objectivity in mind, not based on a
solution of any form.

Another alternative is to delay this document until we select a protocol.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Aug 2003 23:40:01 -0400

Look, I understand the desire to support multicast communication.

However, securing multicast communication is a research area, not an
engineering area.  It is possible that the Forces use of multicast you
envision is one that we know how to secure.  But it is going to be
difficult to write general text for that case.
We are under instructions (for good reason) to include security in the
document.
There is no reasonable way that general security text can be written to
allow for securing general multicast, given the current state of the art.
As such, it is not reasonable to ask the authors to generalize the text in
this regard.

If you have specific text that would still indicate that security will be
provided, but you feel can better allow for what you want, send text to the
list.

Yours,
Joel M. Halpern