Hi Ben,
Please see inline...
-- Avi Lior
--Bridgewater Systems
eview Date: 2011-06-03
IETF LC End Date: 2011-06-03
Summary:
This draft is almost ready for publication as a proposed standard. I
have a question concerning the procedure for generating PSKs, and a
number of minor and editorial comments.
Major issues:
The draft says that the procedure that the HAAA follows to generate the
PSK is out of scope. But doesn't the IKE2 initiator need to understand
the procedure? If the procedure is not defined somewhere, how you
achieve any degree of interoperability?
[VC] Indeed the IKEv2 initiator needs to understand the procedure.
However, this draft focuses on IKEv2 server, as a Diameter client, to
the Diameter server communication for IKEv2 with pre-shared key based
authentication, and specifies Diameter application for this
communication. It is left to specifications that make use of this
Diameter application to specify where the PSK comes from and how it is
generated. There are two 3GPP2 specs that make use of this Diameter
application and both of those specs specify generation of the PSK.
Statements to clarify this are added in v8.
The effect of this is that this spec, as written, cannot be implemented
in an interoperable way. I don't think that meets the usual expectations
for a proposed standard. Now, I realize there are some situations where
the IETF has chosen this approach, and deliberately created a standards
track RFC that must be profiled for actual use--but hopefully that's the
exception rather than the rule. I guess it's up to the IESG to decide if
that is reasonable in this instance. (I'm explicitly not counting
situations where the IETF puts out a standard as a series of modular
RFCs, since I gather there's no immediate intent to publish PSK
generation RFCs.)
Additionally, whether or not PSK generation mechanisms are specified in
the IETF vs somewhere else, how does an implementation (that might
support more than one such mechanism) know which to use for any given SA?
Is there a negotiation mechanism?
I agree with your comments in general. What we need to keep in mind though
is the intent of this draft, which is to deliver the PSK key to the IKEv2
server. The issues you discuss relating to PSK are issues that are there
with or without this document. The document uses all the information that
is available in IKEv2 to fetch that PSK and to allow a PSK to be derived
(via the nonces).
Minor issues:
[...]
[...]
-- section 10, 1st paragraph: "Furthermore, any agents that process
IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this
reason, this specification strongly recommends avoiding Diameter agents
when they cannot be trusted to keep the keys secret."
Should that be normative? Is there no way to protect the PSK AVP from
diameter agents? E.g. can it be encrypted?
[VC] It is hard to use normative text here as this application can be
used for many uses cases. Depending on the use case it may be possible
to encrypt the PSK, however it is not possible to make it a requirement.
I don't see why a "SHOULD" or "RECOMMENDED" would cause problems here,
along with some short explanation of why it might not always be possible.
Otherwise, the text says "strongly recommends", when, without normative
text, such recommendation is really pretty weak.
I may be okay with using stronger terms (SHOULD or RECOMMEND). I actually
wish now that this entire paragraph be deleted. The reason being is that
the security issues relating to multi-hop Diameter communication is well
understood and documented in 3588 (and we already make a reference to that
document). I don't see a need for recommendation.
[...]
Nits/editorial comments:
[...]
-- section 8, first paragraph: "whether the AVP MAY be encrypted."
I don't see anything about encryption in the table.
[VC] The text referring to encryption is deleted.
So how does an implementor know if it can be encrypted?
We used an old style of table which is not really used. There is no end
to end encryption mechanisms in Diameter. And Diameter provides transport
level security (integrity and privacy protection). If the end to end
encryption that is between the Diameter Client (IKEv2 Server) and the
Diameter Server (where the PSK is stored/generated) is needed it would
have to be built on-top of this document - so the implementor will know.
[...]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf