RE: [Nea] IETF67 NEA WG Meeting summary

["Stephen Hanna" <shanna at juniper.net>]

If there are legitimate risks to deploying NEA protocols,
then I'm perfectly OK with discussing those. But I think
those discussions must happen in the proper context.
We should not be debating whether IETF should do NEA.
Instead, we should be discussing what risks arise from
the use of NEA protocols and how those risks can be addressed.

Your discussion below about the need for NEA clients to
authenticate NEA servers before revealing configuration
information is a great example of a constructive idea
for addressing the risks of NEA protocols.

Would it be best to step back and try to enumerate the
risks that can arise from the use of NEA protocols?

Thanks,

Steve

-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu] 
Sent: Tuesday, November 14, 2006 9:25 AM
To: Stephen Hanna
Cc: Blumenthal, Uri; nea at ietf.org
Subject: Re: [Nea] IETF67 NEA WG Meeting summary

> I seem to be Mr. Charter these days.
> 
> Our charter says "NEA is applicable to computing
> enterprise environments, where endpoints accessing the enterprise's
> network are owned and/or expected to conform to the policies set forth
> by the organization that owns and operates the network. All other
> cases are outside the scope of the NEA charter, since we do not know
> that NEA would be useful in such cases."
> 
> So the corporate environment described by Uri is not
> a corner case. It's the only case we're allowed to consider.

wrong.  it _is_ a corner case.  it might be the anticipated use case for

NEA but it's not the only case that NEA will have to deal with, because 
  many hosts that have NEA installed will be used to connect to multiple

networks.  the security risks associated with installing an NEA server 
on your machine and connecting to other networks have to be considered 
in a discussion of NEA requirements.

I'll give you an example of how this impacts the protocol.  let's say 
that we declare that a machine has only one owner and that any 
particular interface on the machine is either connecting to a network 
owned by the same party or a different party.  NEA should only come into

play if the two parties are the same.  we can design a protocol to 
enforce those constraints.  the protocol could require that NEA requests

be signed with a private key, and that NEA server implementations only 
respond to requests that are signed with a private key that matches the 
public key of the owner as configured on the machine, and furthermore 
than NEA server implementations MUST NOT support more than one owner. 
that _might_ solve the problem.

(though I doubt it because there will generally be a need to support 
multiple key pairs at any one time so that the single owner can do 
rollover from old to new keys.  but maybe there's a way around this)

> Let's stop talking about fascist governments and such.

I strongly object to your attempt to discourage this group from 
considering valid risks associated with NEA, and sincerely believe that 
by doing so you are violating IETF policy.

Keith

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea