RE: [Nea] RE: Updated problem statement I-D
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.