Subject: [Nea] NEA requirements and internationalization

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 10 Aug 2007 18:22:49 -0400

Requirement PA-8 is the only place where we mention
string attributes and internationalization issues.
I'm not sure there's a special kind of string attribute.
I think instead we should probably have a common
requirement that says something like "The protocols
MUST support encoding any strings intended for display
to a user with an encoding standard that supports
internationalization." Maybe we should also require
that the protocols support language tags for those
strings or even that they support language negotiation.
Or maybe we should avoid sending user-visible strings!

Thanks,

Steve

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: Alan DeKok <[email-masked]>
Date: Sun, 12 Aug 2007 09:21:33 -0400

> strings or even that they support language negotiation.

  Tags, yes.  Negotiation, no.  Each user on an end host in NEA will
understand at least one language, which can be configured statically
when the NEA client is configured.  The server can remember those
associations.

> Or maybe we should avoid sending user-visible strings!

  I strongly recommend sending user-visible strings, much as that may
cause protocol problems.  Many existing access protocols have provisions
for sending user-visible strings, but implementations don't use them.
When people are denied network access, they get a message that says
"failed", rather than anything informative.

  This lack of information causes many headaches for both users and
administrators.

  I would say thet the protocol MUST have provisions for sending
messages that are intended to be displayed to the user.

  Alan DeKok.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 12 Aug 2007 09:16:53 -0700

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "Stephen Hanna" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 12, 2007 6:21 AM
Subject: Re: [Nea] NEA requirements and internationalization

> when the NEA client is configured.  The server can remember those

This means that the NEA Client must be interactively configured?

> "failed", rather than anything informative.

I dont... From a security sense this may invalidate the use of NEA in many 
instances including probably all of the ones you are shooting for.

>  This lack of information causes many headaches for both users and

The sending of plain-text anywhere is a no-no from a security standpoint.

> messages that are intended to be displayed to the user.

That implies that the system is up and running and that some instance of a 
shell or UI is open so that this messaging can take place. If the session is 
not open then a listener would need to be built for these messages.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 12 Aug 2007 12:55:33 -0400

> This means that the NEA Client must be interactively configured?

  MAY, rather than MUST.  Many sites will have a site-wide configuration
saying "language used by everyone here."

> I dont... From a security sense this may invalidate the use of NEA in
> many instances including probably all of the ones you are shooting for.

  I'm not sure what you mean by that.

  I would like the ability for administrators to push messages to end
users via NEA.  This involves the *capability* to transport
internationalized strings in NEA.  However, those strings are
informative to the end user, and opaque to the rest of NEA.

> The sending of plain-text anywhere is a no-no from a security standpoint.

  I can understand this on the wide open net.  For the chartered purpose
(enterprises), I don't see why it's a problem.

  If you trust the NEA system enough to install the client, displaying
text strings has minimal additional security impact.  If you don't trust
the NEA system, you won't get network access, and you won't see any
strings transported in NEA.

> That implies that the system is up and running and that some instance of
> a shell or UI is open so that this messaging can take place. If the
> session is not open then a listener would need to be built for these
> messages.

  No.  They can be thrown away.  Many PPP implementations have done this
for years.  It's annoying, but widely accepted practice.

  Alan DeKok.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 12 Aug 2007 11:31:51 -0700

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Stephen Hanna" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 12, 2007 9:55 AM
Subject: Re: [Nea] NEA requirements and internationalization

> saying "language used by everyone here."

So then you are suggesting that as part of the entitlement-enablement 
process that the client is interactively configured. Do you mean somewhat 
like setting up a PXE boot process? and does that mean that the basic client 
is BIOS level? - that's not a bad idea too. Intel's super BIOS has plenty of 
room in it and is available for additions like that too, so I could see NEA 
as something that HW manufacturers would want to include into their 
boot-processes. That also gives you a capability for routers and other 
infrastructure as well as appliances.

>  I'm not sure what you mean by that.

What I am saying is that based on new requirements from the Courts (as of 
May 4th 2007) in the US there are now five specific tests for ESI 
(Electronicially Stored Information) into the Court's as evidence, and what 
that means is that in any system that 'may produce content that may come to 
be reviewed as evidence' will need to meet these new requirements.

What that means to us, is that if we are designing technologies to meet 
specific control requirements, there are now new constraints on those 
systems which would come to be used in officia capacities.

The justification for this is not worth arguling here but offlist if you 
want I can explain in detail which pieces of law constrain this claim per. 
BTW - I would involve Jorge, the IETF's Counsel in that offlizt discussion 
so that there was a 'IETF voice' there as well. And while Jorge may say that 
the civil courts have not affirmed my assertion, he cannot deny that I am 
before the US Appellate and that I do have a motion to affirm Judge Grimm's 
ruling as a basic rule for all courts in the US. My take is while I may lose 
my appeal, that they will affirm the Grimm ruling as it it the only chance 
the Courts have to keep functioning.

That said, since there are new 'requirements' in operating official systems, 
NEA should address those too... and that said, passing plain-text about is a 
no-no
> informative to the end user, and opaque to the rest of NEA.

So do a table of messages based on the entitlement models supported and then 
publish UTF-8 strings of them in whatever language you want to support.

> (enterprises), I don't see why it's a problem.

Integrity of the Audit Process running inside the "Entity".  Think of your 
average University for instance. How many would-be hackers are inside the 
Entity then.

> for years.  It's annoying, but widely accepted practice.

Depending what type of auditing and integrity of process model NEA is to 
support.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 12 Aug 2007 21:38:29 -0400

TS Glassey wrote:
> process that the client is interactively configured.

  MAY be interactively configured.  Or, as many administrators do, th
process may be scripted.

> What I am saying is that based on new requirements from the Courts (as
> of May 4th 2007) in the US there are now five specific tests for ESI
> (Electronicially Stored Information) into the Court's as evidence, and
> what that means is that in any system that 'may produce content that may
> come to be reviewed as evidence' will need to meet these new requirements.
> 

  NEA is working on protocol level requirements and design.  Logging,
UI, and legal issues are (IMHO) out of scope.  An NEA requirement that
systems MAY transport user-visible strings is fine.  However, certain
implementations in certain jurisdictions MAY have additional
requirements on what is done with those strings.

  If we design NEA for the lowest-common legal denominator, then we will
have a system that does nothing.

> That said, since there are new 'requirements' in operating official
> systems, NEA should address those too... and that said, passing
> plain-text about is a no-no

  I'm a little at a loss to see how we can design an access protocol
that doesn't tell the user whether or not they've been granted access,
or even if they've been denied.  A list of canned status/error messages
isn't good enough, as experience has shown.

> So do a table of messages based on the entitlement models supported and
> then publish UTF-8 strings of them in whatever language you want to
> support.

  Can we enumerate *enough* possible messages to be useful?  I doubt it.

> Integrity of the Audit Process running inside the "Entity".  Think of
> your average University for instance. How many would-be hackers are
> inside the Entity then.

  Charter.  We have it.  We should focus on it.  Universities are out of
scope.  Issues with deploying NEA inside of Universities are out of
scope.  If certain designs work in an enterprise, but not in a
university, then issues with the university deployment are irrelevant.
They are canards, and out of scope.

>> [ re: informational messages ]

  I'm not really sure what you mean by that.  Informational messages
are... informational.  They have little definitive meaning.

  In contrast, messages like "you must upgrade now" are not
informational.  They impose normative requirements on the user, and
should be logged, audited, etc.

  Alan DeKok.

---

From: "Stephen Hanna" <[email-masked]>
Date: Mon, 13 Aug 2007 08:35:57 -0400

Returning the focusing to internationalization...

One easy way to determine the user's preferred language(s)
is for the Posture Broker Client to read this information
from the operating system or platform (e.g. POSIX locale,
Java Locale, Windows Locale) and pass this information to
the Posture Broker Server early in the NEA exchange. The
Posture Broker Server can then attempt to adapt any human-
readable messages to the user's preferences.

Posture Broker Clients can provide ways to override the
locale info if they want to get really fancy and Posture
Broker Servers can ignore this info if they don't support
the language(s) requested. But it's a good simple solution.

This approach avoids the need for any administrative
configuration, maintaining databases of user preferences,
etc. It's used in HTTP (RFC 3282 Accept-Language tag) and
in the TNC specs. Why not use this technique?

Thanks,

Steve

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Aug 2007 10:15:23 -0400

> readable messages to the user's preferences.

  Sounds good to me.

> in the TNC specs. Why not use this technique?

  Yes.  Let's not re-invent the wheel.

  Alan DeKok.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 13 Aug 2007 07:46:23 -0700

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "Stephen Hanna" <[email-masked]>
Cc: "TS Glassey" <[email-masked]>; <[email-masked]>
Sent: Monday, August 13, 2007 7:15 AM
Subject: Re: [Nea] NEA requirements and internationalization

>> the Posture Broker Server early in the NEA exchange.

This works from a mechacanical standpoint ONLY if those systems are operated 
for use in a particular language-centric  model. For instance, in most cases 
any English Systems will be based on English instances of the OS, but a 
Japanese Instance of say Solaris could easily be operated out of San 
Francisco, and in fact many are. That said the UNAME type output from the 
System is not satisfactory to be the sole determining anchor as to what 
Jurisdiction and Set of Laws that system is operated under and those while 
seemingly non-technical, are in fact pretty critical to all concerns. That 
said the only solution is some form of language and jurisdiction specific 
handshake between the components... Which is EXACTLY what we proposed to 
PKIX some years ago... A process for making a determination under what set 
of rules (language, laws, etc) a connection or event was to be processed. 
This is still missing from NEA and ALL of the PKIX efforts, and needs to be 
added IMHO.

> > The

You mean to the Administrator's preferences right?

>> in the TNC specs. Why not use this technique?

Because Language is ONLY a part of what the NEA needs to be able to specify, 
but if language is to be the totality of the scope then fine... 3282's 
mechanism will work. Its just not expandable to include the other key info 
that NEA needs to pass as well.

---

From: "Stephen Hanna" <[email-masked]>
Date: Mon, 13 Aug 2007 10:58:43 -0400

Sounds like we're getting close to agreement on how to
handle language and internationalization. Since we're
still at the requirements stage, we should probably
focus on requirements and step back from the details
of how things will be done.

I propose deleting requirement PA-8 and adding a new
common requirement saying "For any strings intended
for display to a user, the protocols MUST support
adapting these strings to the user's language preferences."

Comments?

Thanks,

Steve 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, August 13, 2007 10:15 AM
To: Stephen Hanna
Cc: TS Glassey; [email-masked]
Subject: Re: [Nea] NEA requirements and internationalization

  Sounds good to me.

  Alan DeKok.

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 13 Aug 2007 09:37:13 -0700

Hi Steve,

You proposed change seems fine to me; string handling is handled by layers
other than PA and internationalization should be a common requirement.

regards,
  kaushik

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 13 Aug 2007 10:59:04 -0700

I agree it should be a common requirement since it may affect PB as
well.  Unless there are comments with your proposed text, we'll add it
to the draft.  Is everyone happy with the way this proposal is worded
(particularly "protocols MUST support adapting")?  This wording is
oriented towards the processing of the strings by the protocol endpoints
as opposed to the way its represented on the wire as per the old PA
wording below:

"PA-8 String attributes MUST support being encoded with an encoding
standard that supports internationalization."

Paul 

> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Monday, August 13, 2007 7:59 AM
> To: Alan DeKok
> Cc: [email-masked]
> Subject: RE: [Nea] NEA requirements and internationalization
> 
> Sounds like we're getting close to agreement on how to handle 
> language and internationalization. Since we're still at the 
> requirements stage, we should probably focus on requirements 
> and step back from the details of how things will be done.
> 
> I propose deleting requirement PA-8 and adding a new common 
> requirement saying "For any strings intended for display to a 
> user, the protocols MUST support adapting these strings to 
> the user's language preferences."
> 
> Comments?
> 
> Thanks,
> 
> Steve 
> 
> is for the 
> > Posture Broker Client to read this information from the operating 
> > system or platform (e.g. POSIX locale, Java Locale, Windows Locale) 
> > and pass this information to the Posture Broker Server early in the 
> > NEA exchange. The Posture Broker Server can then attempt to 
> adapt any 
> > human- readable messages to the user's preferences.
> 
>   Sounds good to me.
> 
> > This approach avoids the need for any administrative configuration, 
> > maintaining databases of user preferences, etc. It's used 
> in HTTP (RFC 
> > 3282 Accept-Language tag) and in the TNC specs. Why not use this 
> > technique?
>

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 14 Aug 2007 17:53:37 -0700

Alan - pardon the tone of this. Nothing personal is meant by these responses 
but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... Now 
that said - I am NOT against NEA just I want it to do more than what I 
already have implemented with DHCP and several other tools including 
Tripwire. Otherwise its doomed in my estimation.

Todd
----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Stephen Hanna" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 12, 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and internationalization

>  MAY be interactively configured.  Or, as many administrators do, th

scripting opens the system to security issues. It also enables many types of 
script driven attacks too.

> UI, and legal issues are (IMHO) out of scope.

its a good thing its just an opinion... what I am talking about is what is 
required to place technologies into SOX and other regulated entities, and if 
the IETF doesnt want to deal with those then it should specifically say that 
in the scope statement to elminate the issues of legal compliance 
requirements.

The problem is that most techies here have no idea what the law is doing to 
IT requirements and yet people continue to design technologies intentionally 
to fail to meet those requirements. The really funny thing to do is to 
listen to the IT Manager try and talk their way out of being dinged by the 
IT Auditor's for running unsecured and rediculously stupid code in their 
system, and as it happens I think that NEA is the next one of these winners 
to come out of the IETF.

The issues are simple - and that is if there is a desire to install a system 
that can pre-qualify the security compliance and platform configuration 
compliance into the IT world then it needs to do so in concert with the 
Auditor's who will tell the IETF whether they are willing to put their names 
and professional reputation/credentials on the line by using this protocol 
as  their recommendation. Otherwise why bother?

> An NEA requirement that

The EU Data Integrity "regulation" may not agree with you.

> have a system that does nothing.

No - but that is the typical claim from techies who dont know what they are 
designing to. The problem with NEA is that there are regulatory requirements 
for this type of thing and the NEA WG wants to build something else that 
doesnt address those but claims to apparently.

> or even if they've been denied.

Uh simple - the users NIC can easily be used to tell them all kinds of 
things including NO CONNECTION.

> A list of canned status/error messages

Sure - a common set of messages is all that is necessary and simple UTF-8 
Encoding to make those transportable.

> They are canards, and out of scope.

Screw the Academic issues, as a professional auditor I believe that you nor 
no one else here will install NEA in its current form in any regulated 
networks period. I just wont fly with what you got now, whether you like 
that or not, and whether you believe it or not...

> are... informational.  They have little definitive meaning.

Uhh is NEA a tool for qualifying systems prior to accessing the entity 
resources?

> should be logged, audited, etc.

Agreed as should any status message from any transaction.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Aug 2007 22:38:57 -0400

TS Glassey wrote:
> Alan - pardon the tone of this. Nothing personal is meant by these
> responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a
> while...

  It's nice to know that my attempts at achieving consensus cause such
good feelings.

> scripting opens the system to security issues. It also enables many
> types of script driven attacks too.

  From who?  Unless I'm mistaken, NEA is about giving known and trusted
administrators the ability to require the end host to download something
 called "software updates".

  If you're worried about script attacks from people within a circle of
trust, I suggest you give up on NEA entirely.

> The problem is that most techies here have no idea what the law is doing
> to IT requirements and yet people continue to design technologies
> intentionally to fail to meet those requirements.

  That statement is rather a lot stronger than what I said.

  Please explain how we can design NEA to fulfill all legal requirements
in all jurisdictions.  If we can't do that, then we should give up on
NEA now.  Or, we should pick a jurisdiction that is understood, and
design NEA to work only there.

  Since NEA has been chartered, the first option is off of the table.
Since the IETF is an international group, the second option is off of
the table.

  Please come up with constructive suggestions as to *how* something
positive can be done.  All you've done so far is to state absolute
requirements.

> The EU Data Integrity "regulation" may not agree with you.

  The EU Data Integrity "regulation" specifies that user-visible strings
MAY NOT be transported?  Or maybe you mean that the EU Data Integrity
"regulation" MAY NOT have any requirements on what is done with
user-visible strings?

  I'm trying to figure out how your statement bears any relation to what
I said.  I'm failing.

> No - but that is the typical claim from techies who dont know what they
> are designing to.

  Design to meet Iran's requirements.  Don't know them?  I'll mock you
mercilessly, and ridicule your position on the list.

  Ah, the refreshing breeze of open communication.

> The problem with NEA is that there are regulatory
> requirements for this type of thing and the NEA WG wants to build
> something else that doesnt address those but claims to apparently.

  I don't think we're reading the same list.

>> isn't good enough, as experience has shown.

  Yup.

> Sure - a common set of messages is all that is necessary and simple
> UTF-8 Encoding to make those transportable.

  If there is a common set of messages that can be defined, then simple
integer status codes will suffice.  If a common set of messages can't be
defined, then user-visible strings are required.  See above for my
opinion on the topic.

> Screw the Academic issues, as a professional auditor I believe that you
> nor no one else here will install NEA in its current form in any
> regulated networks period. I just wont fly with what you got now,
> whether you like that or not, and whether you believe it or not...

  So you disagree with the charter.  Why are you still here?

  Alan DeKok.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Aug 2007 08:56:19 -0700

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Stephen Hanna" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 14, 2007 7:38 PM
Subject: Re: [Nea] NEA requirements and internationalization

>  It's nice to know that my attempts at achieving consensus cause such

:-)

>> types of script driven attacks too.

MITM attacks are what I am worried about - and anything that happens from a 
configuration control aspect inside of controled networks needs to be both 
secured/authenticated and fully logged on an end-to-end basis.

> trust, I suggest you give up on NEA entirely.

Do you know about the separation of Roles and Responsibilities within the 
existing Audit Models. NEA Administrator's are likely NOT to be user 
administrator's except in smaller entities. So it is appropriate that only 
some of the admins in any entity have access to NEA facilities.

>  That statement is rather a lot stronger than what I said.

It is, and I apologize for offending anyone with a sensitive ego, but the 
reality is what it is. Let me ask - Why do you think that these Federal 
Entitie's which are being publicly spanked for IT Failings are failing???

Is it the Government itself? I dont think so - its because those 
administrator's, who were trained by those folks out of the 70'sthrough 90's 
IT world's are assuring everyone that their systems are 'solid', and as it 
happens they are not.

This ISNT and WASNT my doing... I am just noticing that those people failing 
the current operations requirements are the same people who before SOX and 
the FISCAM requirements were signing documents saying that they assured the 
management that their sites were secure.

These failings didnt happen overnight, they were always there. Hell - I was 
attacking systems for one of the clients I worked for with Buffer-Overflows 
in 1998. Their client's included the US Navy and other financial entities so 
this is not new stuff or rocket science. That said - YES I am slamming those 
admins and most of those outside the Government too for just not 
understanding what is necessary to run a secured and audited shop, and (here 
comes the rub) for assuring the world that they did.

> design NEA to work only there.

Simple - For SOX Compliance create a set of COBIT practice control models 
that rely on NEA and draft a procedure for installing and managing a new 
platform or ongoing status-compliance therein. The same is true for HIPAA 
Compliance in Medical Processes.

> positive can be done.  All you've done so far is to state absolute

Lets document the use then of that COBIT compliance model - I will draft a 
NEA use document that addresses these control issues and file it as an I-D. 
The IETF can then formally inform ISACA that it has a COBIT practice model 
available for use by ISACA professionals and others for using NEA as a part 
of a COBIT compliance model.

> "regulation" MAY NOT have any requirements on what is done with

Both depending on what messages are sent. That is why its important to 
pre-define the messages and their respons processes.

> mercilessly, and ridicule your position on the list.

What I am saying is that designing for the purpose of desing itself is Art. 
Desinging for some specific purpose is what we are about here I thought, so 
lets define the uses of NEA and then meet those needs with technologies 
specific to those requirements.

>  Ah, the refreshing breeze of open communication.

:-)

>  So you disagree with the charter.  Why are you still here?

No I dont disagree with the Charter, I just think its too narrow to meet any 
specific end-use.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Aug 2007 16:11:36 -0400

todd glassey wrote:
> No I dont disagree with the Charter, I just think its too narrow to meet
> any specific end-use.

  I guess there isn't much point in continuing.  I'm trying to be
productive, and you're not.

  Alan DeKok.

---

From: Frank Yeh Jr <[email-masked]>
Date: Wed, 15 Aug 2007 21:33:28 -0700

Greetings,

      Todd, based on your argument below, wouldn't we have to eliminate use
of TCP/IP in all deployments affected by compliance auditing?

      Compliance does not have to be built into the network protocols, nor
would it be wise to try to do this. Compliance is something that happens at
Layer 7, NEA is shooting at about Layer 2.

      If you want to get into a discussion into legal aspects of
compliance, IBM has a few hundred lawyers who will engage and make sure
that you never get anything meaningful done ever again (trust me, I've been
there).

Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

             "TS Glassey"                                                  
             <tglassey@earthli                                             
             nk.net>                                                    To 
                                       "Alan DeKok"                        
             08/14/2007 05:53          <[email-masked]>         
             PM                                                         cc 
                                       [email-masked]                        
                                                                   Subject 
                                       Re: [Nea] NEA requirements and      
                                       internationalization                

                                                                           

responses

Todd
----- Original Message -----
From: "Alan DeKok" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Stephen Hanna" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 12, 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and internationalization

>  MAY be interactively configured.  Or, as many administrators do, th

scripting opens the system to security issues. It also enables many types
of
script driven attacks too.

its a good thing its just an opinion... what I am talking about is what is
required to place technologies into SOX and other regulated entities, and
if
the IETF doesnt want to deal with those then it should specifically say
that
in the scope statement to elminate the issues of legal compliance
requirements.

IT requirements and yet people continue to design technologies
intentionally

to come out of the IETF.

The issues are simple - and that is if there is a desire to install a
system
that can pre-qualify the security compliance and platform configuration
compliance into the IT world then it needs to do so in concert with the
Auditor's who will tell the IETF whether they are willing to put their
names
and professional reputation/credentials on the line by using this protocol
as  their recommendation. Otherwise why bother?

designing to. The problem with NEA is that there are regulatory
requirements
for this type of thing and the NEA WG wants to build something else that
doesnt address those but claims to apparently.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 16 Aug 2007 07:25:17 -0700

Sorry Frank, I disagree - more inline below... 

  ----- Original Message ----- 
  From: Frank Yeh Jr 
  To: TS Glassey 
  Cc: Alan DeKok ; [email-masked] 
  Sent: Wednesday, August 15, 2007 9:33 PM
  Subject: Re: [Nea] NEA requirements and internationalization

  Greetings,

  Todd, based on your argument below, wouldn't we have to eliminate use of TCP/IP in all deployments affected by compliance auditing?

Not from my viewpoint. But the issue is in creating systems which use what is available to accomplish those requirements.  So "No... IP can be audited" it just takes an additional amount of overhead to do it. 

XNS by comparison, and even OSX/SPX were better protocols for that type of thing. And remember what TCP/IP was designed to do. Its a demonstration protocol built under contract to ARPA by BB&N to facilitate the operations of the Air Force's data exchange network with military and academic institutions. It (TCP/IP) was never built to be secured or audited in the sense of something say like the services provided electronically from the Federal Reserve Bank or like entities. And YES Frank I still have one of Stanford's old Honnywell H316 IMP's in my garage so... 

By the way - inside the DoD and intelligence Community, CIPR and NIPR net's replaced the ARPA Net for secured communications so formally the US Military itself DOESNT rely on publicly routed TCP/IP like the rest of us do...

  Compliance does not have to be built into the network protocols, nor would it be wise to try to do this. 

Boy is that a broken statement. Sorry Frank you ARE wrong here - and that is part of the problem with why the Audit Community is estranged from this Standards Body. Compliance with regulatory requirements happens at ALL levels and that is simply that. The problem with layering compliance on the Application Layer is that it requires a fully-functional station prior to compliance being determined. Which is why NEA's working at Layer-2/3 is so important. Application Layer certification means that the OS is already up and running on the client-node and that means that prior to its being authorized to participate in that network's operations it is already a threat to the integrity of the system...

And yes - we can thank the design of IP for that.

  Compliance is something that happens at Layer 7, NEA is shooting at about Layer 2.

Frank... You actually mean layer 4 right? See TCP/IP was not designed on the ISO OSI model but rather prior to the ISO's Seven Layer OSI Model's birth.

  If you want to get into a discussion into legal aspects of compliance, IBM has a few hundred lawyers who will engage and make sure that you never get anything meaningful done ever again (trust me, I've been there).

Actually - I formally presented IBM's General Counsel with a set of compliance questions, and they refused to answer or even acknowledge that they had been asked. I asked Lou Lupin, General Counsel of Qualcomm the same Questions and Mark Chamber's, General Counsel of Cisco the same set. Cisco was the only one that answered the questions by the way, so again Frank I disagree. 

Todd Glassey

  Regards,
  Frank Yeh

  "TS Glassey" <[email-masked]>

                "TS Glassey" <[email-masked]> 
                08/14/2007 05:53 PM

              To 
              "Alan DeKok" <[email-masked]> 

              cc 
              [email-masked] 

              Subject 
              Re: [Nea] NEA requirements and internationalization 

  Todd

---

From: Frank Yeh Jr <[email-masked]>
Date: Thu, 16 Aug 2007 08:40:39 -0700

Todd,

      I am fine with not being in agreement.

      We just have a different philosophy when it comes to how this should
all be approached.

      More in line below, this round's comments tagged with FYEH:.

Regards,
Frank Yeh

                                                                           
             "todd glassey"                                                
             <tglassey@earthli                                             
             nk.net>                                                    To 
                                       Frank Yeh Jr/Irvine/IBM@IBMUS       
             08/16/2007 07:25                                           cc 
             AM                        "Alan DeKok"                        
                                       <[email-masked]>,        
                                       <[email-masked]>                      
                                                                   Subject 
                                       Re: [Nea] NEA requirements and      
                                       internationalization                

                                                                           

 ----- Original Message -----
 From: Frank Yeh Jr
 To: TS Glassey
 Cc: Alan DeKok ; [email-masked]
 Sent: Wednesday, August 15, 2007 9:33 PM
 Subject: Re: [Nea] NEA requirements and internationalization

 Greetings,

 Todd, based on your argument below, wouldn't we have to eliminate use of
 TCP/IP in all deployments affected by compliance auditing?

Not from my viewpoint. But the issue is in creating systems which use what
is available to accomplish those requirements.  So "No... IP can be
audited" it just takes an additional amount of overhead to do it.

FYEH: My point is that TCP/IP was not designed for existence in a
compliance and auditing driven environment and yet we contiunue to use it
today and will continue to do so into the future. Your observations about
its history bear this out. We are not going to eliminate TCP/IP soon, so we
are stuck with it and so is the audit community. Do you realistically think
we can replace TCP/IP with something the auditers are comfortable with? How
do we do that? Turn off the internet for a maintenance upgrade? Can we work
that into the IPv6 cutover?

XNS by comparison, and even OSX/SPX were better protocols for that type of
thing. And remember what TCP/IP was designed to do. Its a demonstration
protocol built under contract to ARPA by BB&N to facilitate the operations
of the Air Force's data exchange network with military and academic
institutions. It (TCP/IP) was never built to be secured or audited in the
sense of something say like the services provided electronically from the
Federal Reserve Bank or like entities. And YES Frank I still have one of
Stanford's old Honnywell H316 IMP's in my garage so...

FYEH: LOL! DUDE! It's time to move on! IBM has stopped investing in Token
Ring and SNA even though they offered a host of advantages over ethernet
and IP. The fact that you actually have the honeywell taking up space in
your garage is a bit scary! Donate it to a museum and share this bit of
history with the public.

By the way - inside the DoD and intelligence Community, CIPR and NIPR net's
replaced the ARPA Net for secured communications so formally the US
Military itself DOESNT rely on publicly routed TCP/IP like the rest of us
do...

FYEH: CIPRnet and NIPRnet are both acronyms that include IPR which stands
for Internet Protocol Routers!!! CIPRNet is definitely not publicy routed,
NIPRNet is part of the publicly routed network, with access to many of the
.mil domains being routed through it, but this is a complete non-sequiter.
How you design a protocol and how people use it should not be confused. The
fact that CIPRNet depends on physcial separation probably lends credence o
the fact that TCP/IP is not designed for security or audit but that is a
unique case. The rest of us need to operate in the real world.

Compliance does not have to be built into the network protocols, nor would
it be wise to try to do this.

Boy is that a broken statement. Sorry Frank you ARE wrong here - and that
is part of the problem with why the Audit Community is estranged from this
Standards Body. Compliance with regulatory requirements happens at ALL
levels and that is simply that. The problem with layering compliance on the
Application Layer is that it requires a fully-functional station prior to
compliance being determined. Which is why NEA's working at Layer-2/3 is so
important. Application Layer certification means that the OS is already up
and running on the client-node and that means that prior to its being
authorized to participate in that network's operations it is already a
threat to the integrity of the system...

FYEH: I will agree to disagree on this if you will. IMHO YOU are wrong!!!
;-P I understand what you want at a philosophical level, but if we tried to
build what you desire, we would never be done. You just can't build
everything into a single protocol. We DEPEND on separation at different
layers and interafces between them. These are what the protocols do. You
are right that with this segmentation, we have to prove compliance at a
number of different levels, but this is NOT what NEA is intended to do. It
will be used to provide a reasonably secure way for clients and servers of
applications that normally work at layer 7 to communicate at layer 2 to
establish some level of trust before allowing the network to provide Layer
3 conntectivity.  When you look at the TCG model, there is a whole set of
protocols and practices external to TNC (their version of what NEA is
trying to standardize) to provide a trusted stack with compliance proven at
every level and based on a hardware root of trust.

 Compliance is something that happens at Layer 7, NEA is shooting at about
 Layer 2.

Frank... You actually mean layer 4 right? See TCP/IP was not designed on
the ISO OSI model but rather prior to the ISO's Seven Layer OSI Model's
birth.

FYEH: Enough with the history lessons already!  First of all, I will
concede that PA and PB are probably higher than layer 2. In fact using the
right PT options will allow applications to communicate over the network
without end-to-end TCP/IP connectivity. So the tunnel's endpoints are
probably best described at Layer 5. The protocols that PT will ride
probably end up with a layer 2 endpoint on the client end but that is
outside of scope. However, didn't you say above that NEA working at Layer
2/3 was important?

 If you want to get into a discussion into legal aspects of compliance, IBM
 has a few hundred lawyers who will engage and make sure that you never get
 anything meaningful done ever again (trust me, I've been there).

Actually - I formally presented IBM's General Counsel with a set of
compliance questions, and they refused to answer or even acknowledge that
they had been asked. I asked Lou Lupin, General Counsel of Qualcomm the
same Questions and Mark Chamber's, General Counsel of Cisco the same set.
Cisco was the only one that answered the questions by the way, so again
Frank I disagree.

FYEH: I am all about keeping the lawyers out of the network protocols.
Without seeing the set of questions you presented it is pretty hard to
comment on why IBM declined to comment or acknowledge but as I have
indicated, we have too many lawyers who are basically paid to keep us out
of litigation. They are a bit nervous and protective by nature. They always
err on the side of safety. Allowing compliance and auditing mindsets to
drive technology is a dangerous thing IMHO.

Todd Glassey

 Regards,
 Frank Yeh

 Inactive hide details for "TS Glassey" <[email-masked]>"TS
 Glassey" <[email-masked]>

                         "TS Glassey"                                      
                         <tglassey@ear                                     
                         thlink.net>                                       
                                                                           
                                                                        To 
                         08/14/2007                                        
                         05:53 PM                    "Alan DeKok"          
                                                     <aland@deployingradiu 
                                                     s.com>                
                                                                           
                                                                        cc 
                                                                           
                                                     [email-masked]          
                                                                           
                                                                   Subject 
                                                                           
                                                     Re: [Nea] NEA         
                                                     requirements and      
                                                     internationalization  

                                                                           

 Todd
 ----- Original Message -----
 From: "Alan DeKok" <[email-masked]>
 To: "TS Glassey" <[email-masked]>
 Cc: "Stephen Hanna" <[email-masked]>; <[email-masked]>
 Sent: Sunday, August 12, 2007 6:38 PM
 Subject: Re: [Nea] NEA requirements and internationalization

 to

 IT Auditor's for running unsecured and rediculously stupid code in their
 system, and as it happens I think that NEA is the next one of these
 winners
 to come out of the IETF.

 are

 nor

---

From: "todd glassey" <[email-masked]>
Date: Thu, 16 Aug 2007 09:24:46 -0700

Frank,
Cool - everyone is entailed to an opinion. Mine is of a certified auditor; so I am not just blowing smoke when I tell you that without certain concessions to integrity and its ongoing demonstration, NEA probably wont see the light of day in commercial networks; This claim is based on what we have had to do to document compliance with PCAOB's AS-2 and then later AS-4 and AS-5 standards for Auditing. 

It (my opinion)  is also based on what those customers have already paid to their internal and external auditor's to certify what they already have in place... so why would they want to make that expense something that they redo again and again everytime there is a new NEA release or standards specification? - their shareholders will kill them. Their stakeholders will also say "no" too IMHO based on the continuously increasing overhead.

NEA has real possibilities as a base-line compliance messaging service and that's its real value in the commercial world, whether the consensus here in this WG says the same or not. This is not about standards and the creation thereof its about what the Industry needs for its operations and the compliance hurdles facing every major network operator on the Globe today. That all said - my position is the same. That being the above and that I feel that NEA's key value is then in several of the things specifically noted as 'outside NEA's Scope'... 

Todd's 2 Cents (as a private citizen, but one with CISM and CIFI auditing credentials)
  ----- Original Message ----- 
  From: Frank Yeh Jr 
  To: todd glassey 
  Cc: Alan DeKok ; [email-masked] 
  Sent: Thursday, August 16, 2007 8:40 AM
  Subject: Re: [Nea] NEA requirements and internationalization

  Todd,

  We just have a different philosophy when it comes to how this should all be approached.

  Regards,
  Frank Yeh

  "todd glassey" <[email-masked]>

                "todd glassey" <[email-masked]> 
                08/16/2007 07:25 AM

              To 

              cc 
              "Alan DeKok" <[email-masked]>, <[email-masked]> 

              Subject 

  ----- Original Message ----- 
  From: Frank Yeh Jr 
  To: TS Glassey 
  Cc: Alan DeKok ; [email-masked] 
  Sent: Wednesday, August 15, 2007 9:33 PM
  Subject: Re: [Nea] NEA requirements and internationalization

  Greetings,

  FYEH: My point is that TCP/IP was not designed for existence in a compliance and auditing driven environment and yet we contiunue to use it today and will continue to do so into the future. Your observations about its history bear this out. We are not going to eliminate TCP/IP soon, so we are stuck with it and so is the audit community. Do you realistically think we can replace TCP/IP with something the auditers are comfortable with? How do we do that? Turn off the internet for a maintenance upgrade? Can we work that into the IPv6 cutover? 

  FYEH: LOL! DUDE! It's time to move on! IBM has stopped investing in Token Ring and SNA even though they offered a host of advantages over ethernet and IP. The fact that you actually have the honeywell taking up space in your garage is a bit scary! Donate it to a museum and share this bit of history with the public. 

  FYEH: CIPRnet and NIPRnet are both acronyms that include IPR which stands for Internet Protocol Routers!!! CIPRNet is definitely not publicy routed, NIPRNet is part of the publicly routed network, with access to many of the .mil domains being routed through it, but this is a complete non-sequiter. How you design a protocol and how people use it should not be confused. The fact that CIPRNet depends on physcial separation probably lends credence o the fact that TCP/IP is not designed for security or audit but that is a unique case. The rest of us need to operate in the real world. 

  FYEH: I will agree to disagree on this if you will. IMHO YOU are wrong!!! ;-P I understand what you want at a philosophical level, but if we tried to build what you desire, we would never be done. You just can't build everything into a single protocol. We DEPEND on separation at different layers and interafces between them. These are what the protocols do. You are right that with this segmentation, we have to prove compliance at a number of different levels, but this is NOT what NEA is intended to do. It will be used to provide a reasonably secure way for clients and servers of applications that normally work at layer 7 to communicate at layer 2 to establish some level of trust before allowing the network to provide Layer 3 conntectivity. When you look at the TCG model, there is a whole set of protocols and practices external to TNC (their version of what NEA is trying to standardize) to provide a trusted stack with compliance proven at every level and based on a hardware root of trust. 

  FYEH: Enough with the history lessons already! First of all, I will concede that PA and PB are probably higher than layer 2. In fact using the right PT options will allow applications to communicate over the network without end-to-end TCP/IP connectivity. So the tunnel's endpoints are probably best described at Layer 5. The protocols that PT will ride probably end up with a layer 2 endpoint on the client end but that is outside of scope. However, didn't you say above that NEA working at Layer 2/3 was important? 

  FYEH: I am all about keeping the lawyers out of the network protocols. Without seeing the set of questions you presented it is pretty hard to comment on why IBM declined to comment or acknowledge but as I have indicated, we have too many lawyers who are basically paid to keep us out of litigation. They are a bit nervous and protective by nature. They always err on the side of safety. Allowing compliance and auditing mindsets to drive technology is a dangerous thing IMHO. 

  Todd Glassey 

  Regards,
  Frank Yeh

       
              To 

              cc 
              [email-masked] 

              Subject 

  Todd