[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: DISCUSS: draft-ietf-radext-tcp-transport
I-D Editors,
Please address the issues raised by Tim in his DISCUSS.
Thanks and Regards,
Dan
-----Original Message-----
From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of
Tim Polk
Sent: Wednesday, May 19, 2010 9:55 PM
To: iesg@ietf.org
Cc: draft-ietf-radext-tcp-transport@tools.ietf.org;
radext-chairs@tools.ietf.org
Subject: DISCUSS: draft-ietf-radext-tcp-transport
Discuss:
This is a good document, but there are a few issues that should be
addressed before publication.
(1) The document is inconsistent regarding the applicability of this
protocol.
From the Abstract, where "It" refers to this document:
It is not intended
to define TCP as a transport protocol for RADIUS in the absence of
TLS.
but the last paragraph in the Introduction states:
"Bare" TCP transport MAY, however, be used when another method such
as IPSec [RFC4301] is used to provide additional confidentiality and
security. Should experience show that such deployments are useful,
this specification could be moved to standards track.
(2) In a related point, the next to last paragraph in the Introduction
states:
Since "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required. As a
result the use of "bare" TCP transport (i.e., without additional
confidentiality and security) is NOT RECOMMENDED, as there has been
little or no operational experience with it.
Why isn't this a "MUST NOT be used without TLS, IPsec, or other secure
upper layer"?
(3) The security considerations should include a statement along the
same lines as discussed in (2) - e.g., MUST NOT be used unless TLS or
IPsec is used in conjunction.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>