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

From: "Polansky, Robert" <[email-masked]>
Date: Tue, 7 Mar 2006 09:30:47 -0500

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

---

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 7 Mar 2006 10:47:47 -0800

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
[...]