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

["Thomas Hardjono" <THardjono at SignaCert.com>]

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:rpolansky at rsasecurity.com] 
Sent: Tuesday, March 07, 2006 3:56 PM
To: THardjono at SignaCert.com; nea at ietf.org
Cc: thomas at SignaCert.com
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:THardjono at SignaCert.com]
Sent: Tuesday, March 07, 2006 12:48 PM
To: Polansky, Robert; nea at ietf.org
Cc: thomas at SignaCert.com
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:rpolansky at rsasecurity.com]
Sent: Tuesday, March 07, 2006 6:31 AM
To: nea at ietf.org
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: nea-request at ietf.org [mailto:nea-request at ietf.org]
Sent: Saturday, March 04, 2006 3:42 PM
To: nea at ietf.org
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
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea



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