Subject: RE: [Nea] RE: Updated problem statement I-D

From: "Polansky, Robert" <[email-masked]>
Date: Tue, 7 Mar 2006 18:55:53 -0500

Thomas,

I was really trying to dig more deeply into the "security" reasons for
making the two concepts separable. Your comment about protecting the
data in transit is one example. I was hoping for one or two specific
examples of the security reasons for separability to be in the draft
instead of having the reader infer the security issues.

Thanks.

-Rob

-----Original Message-----
From: Thomas Hardjono [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 12:48 PM
To: Polansky, Robert; [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] RE: Updated problem statement I-D

Rob,

The concept of (i) authentication (user or device) is quite distinct
from
(ii) measuring/reporting the integrity state ("health") of a device.
Each have their respective design and security issues (e.g. when a
health report is being sent from the client to the server, what is used
to protect it in-transit.).

So far the IP networking industry has only seen authentication (i) (eg.
in the form of passwords, SecureID tokens, certs/PKI, etc.)  We have not
really seen an industry-wide adoption of (ii) and hence the NEA BOF.

These two distinct concepts are separable, but need not be separated in
implementations. (For example, in the context of 802.1X with tunneled
EAP methods, some form of authentication mechanism might be used to
identify the end-points wishing to open the outer-tunnel, while the
client health information is sent inside the inner-tunnel. Only the
success of both will lead to a common master-key.)

PS. I must confess I don't really understand the last sentence of your
question ("risk in overloading one architecture with the other's
functionality"). Perhaps you could clarify.

cheers,

/thomas/

-----Original Message-----
From: Polansky, Robert [mailto:[email-masked]]
Sent: Tuesday, March 07, 2006 6:31 AM
To: [email-masked]
Subject: [Nea] RE: Updated problem statement I-D

I would echo others' statements that this is a good statement of the
problem at hand. I know I haven't contributed in the past, but I do have
a request for a minor clarification on section 9.5. It says that "it is
important from a security perspective" to be able to separate end-point
authentication from end-point posture assessment. I understand why you
need to be able to separate the architectures from an engineering
perspective, but I think the document should be more specific as to the
security concerns around why they need to be separable. Is there is risk
in overloading one architecture with the other's functionality?

Thanks.

-Rob Polansky

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, March 04, 2006 3:42 PM
To: [email-masked]
Subject: Nea Digest, Vol 5, Issue 1
[...]
9.5.  Identity authentication of communicating end-points

   In order for the NEA Server to accept access requests and posture
   information being reported to by the NEA client, the NEA Server may
   need to authenticate the NEA client in some manner.  Similarly,
   within some network environments there may be the requirement that
   the NEA client also authenticate the NEA Server with whom it is
   communicating.  Although the process of evaluating an access request
   may combine together the notion of authentication and integrity state
   evaluation (through posture information), it is important from a
   security perspective and useful from a good engineering practices
   perspective to be able to separate end-point authentication
   (including both machine and user authentication) from end-point
   posture assessment.

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

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

---

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 7 Mar 2006 16:46:11 -0800

Thanks Rob.

There really is no "security" reasons for separating the two concepts other
than they are distinct building blocks that participate in a broader
security architecture. Its always wise from a design perspective to identify
building blocks, their functions, limitations and interfaces. Having them
separate also allows a mix-and-match in different deployment scenarios.

Another security consideration (that I did not place in the draft due to
time constraints) is the need for end-point authentication to occur first
before posture assessment.  This is in order to prevent against DOS attacks
that waste cycles of its target (posture collector) in doing repeated
checks.

/thomas/

-----Original Message-----
From: Polansky, Robert [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 3:56 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] RE: Updated problem statement I-D

Thomas,

I was really trying to dig more deeply into the "security" reasons for
making the two concepts separable. Your comment about protecting the data in
transit is one example. I was hoping for one or two specific examples of the
security reasons for separability to be in the draft instead of having the
reader infer the security issues.

Thanks.

-Rob

-----Original Message-----
From: Thomas Hardjono [mailto:[email-masked]]
Sent: Tuesday, March 07, 2006 12:48 PM
To: Polansky, Robert; [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] RE: Updated problem statement I-D

Rob,

cheers,

/thomas/

-----Original Message-----
From: Polansky, Robert [mailto:[email-masked]]
Sent: Tuesday, March 07, 2006 6:31 AM
To: [email-masked]
Subject: [Nea] RE: Updated problem statement I-D

Thanks.

-Rob Polansky

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, March 04, 2006 3:42 PM
To: [email-masked]
Subject: Nea Digest, Vol 5, Issue 1
[...]