|
Re: [IPsec] Last Call: <draft-ietf-dime-ikev2-psk-diameter-06.txt> (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard
2011-06-14 15:48:18
Resending, apologies if you see it twice.
On 06/14/2011 11:18 PM, Yaron Sheffer wrote:
Hi Violeta,
I am fine with the latest version of the document.
Thank you,
Yaron
On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote:
Hi Yaron,
Thanks for the suggestions.
Please see inline.
-Violeta
-----Original Message-----
From: Yaron Sheffer [mailto:yaronf(_dot_)ietf(_at_)gmail(_dot_)com]
Sent: Friday, June 03, 2011 4:32 PM
To: Cakulev, Violeta (Violeta)
Cc:ietf(_at_)ietf(_dot_)org; IPsecme
WG;dime(_at_)ietf(_dot_)org;draft-ietf-dime-ikev2-psk-diameter(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: [IPsec] Last Call:<draft-ietf-dime-ikev2-psk-diameter-06.txt>
(Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter
Server Interaction) to Proposed Standard
Hi Violeta,
thanks for your response.
I understand now where you're coming from. But the next person to read the
document might not have the authors so readily available :-) Implementors need
to understand the motivation for this solution as well as the missing pieces.
[VC] And the next person indeed had the same concern. Therefore, in v8 we made
the changes as proposed below.
So I would suggest that you add:
- A short paragraph in the Introduction putting this document in perspective
and referencing (non-normative references of course) the
3GGP2 documents.
- Another paragraph in the Security Considerations that says that
generation/derivation of the PSK is security-critical, and provides the
3GPP2 docs again as an example of a solution to this problem.
[VC] Please see v8. We added statements both in Introduction and Security
Considerations as proposed above.
Regarding usage of the SPI, the document says: "Upon receiving the IKE_AUTH message
from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi *and the SPI*
if available, to determine if it has the PSK for this IKEv2 Peer."This sounds to me
as if the SPI is used as part of the PSK lookup operation. Maybe the SPI should not be
mentioned in the above text.
[VC] We modified this paragraph in v8. Please see v8.
Best regards,
Yaron
On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote:
Hi Yaron,
Thanks for the comments.
Please see inline [VC].
-Violeta
-----Original Message-----
From:ipsec-bounces(_at_)ietf(_dot_)org
[mailto:ipsec-bounces(_at_)ietf(_dot_)org] On Behalf
Of Yaron Sheffer
Sent: Sunday, May 22, 2011 2:38 PM
To:ietf(_at_)ietf(_dot_)org
Cc: IPsecme
WG;draft-ietf-dime-ikev2-psk-diameter(_at_)tools(_dot_)ietf(_dot_)og;
dime(_at_)ietf(_dot_)org
Subject: Re: [IPsec] Last
Call:<draft-ietf-dime-ikev2-psk-diameter-06.txt> (Diameter IKEv2 PSK:
Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server
Interaction) to Proposed Standard
Hi,
Having read this document only now, I think there's a number of serious issues
with it. This document was sent to the ipsec mailing list a while ago but
unfortunately got no review.
Summary:
1. I think the wrong architectural choice was made, in preferring PSK over EAP
authentication.
2. There is not enough detail in the document to result in interoperable
implementations.
[VC] Please see responses to detailed comments.
Detailed comments:
* The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the
shepherd review back in March.
[VC] This is fixed in v7.
* The document notes that EAP is one of the authentication modes supported by
IKEv2. EAP is designed for interaction with backend AAA servers, and is quite
capable of performing shared-secret authentication, using a variety of EAP
methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the
document does not explain why EAP is not used, instead preferring the IKE PSK
authentication method.
[VC] Diameter application for Diameter client to server communication for IKEv2
with EAP has been specified in RFC 5778. However, there is no Diameter
application specified for IKE PSK authentication method. This is stated in the
draft both in Abstract and Introduction. The draft does not recommend one or
the other, it is simply specifying what is not specified. It is up to a
specific use case to decide what to use. For example 3GPP2 decided to use IKEv2
PSK (in 2 of its specifications), and that is what triggered this effort in
IETF.
* 4.1: how can the incoming SPI be used to identify the peer?
[VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH
message and this payload 'MUST contain an identity that is meaningful
for the Diameter infrastructure, such as a Network Access Identifier
(NAI), since it is used by the IKEv2 Server to populate the User-Name
AVP in the Diameter message'. SPI is not used to identify the peer.
* Packing additional semantics into SPI may conflict with elements of the IPsec
architecture (see for example Sec. 9.3 of
draft-ietf-ipsecme-failure-detection-08).
[VC] Agreed.
* 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be
"outside the scope" of the document. There is no way to interoperate otherwise.
[VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diameter
server communication for IKEv2 with pre-
shared secret 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. As
mentioned above, there are two 3GPP2 specs that make use of this Diameter
application and both of those specs specify generation of the PSK.
* Moreover, if a single client is expected to sometimes use EAP and sometimes
PSK, there must be a way to notify it which one to use.
[VC] This is not the assumption. Again this draft specifies Diameter
application for Diameter client to the Diameter server communication for IKEv2
with PSK. IKEv2 server knows whether EAP or PSK is used.
* How does key-lifetime relate to the lifetime of the IKE SA?
[VC] This should be the same as in RFC 5996, how pre-shared secret lifetime
relates to the lifetime of the IKE SA. This draft should not make any changes.
* Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK is
only used for authentication and does not encrypt anything.
[VC] Good point. It is changed to PSK in v7.
* The same paragraph is very vague about the security properties of PSK.
RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a critical
consideration is how to assure the randomness of these secrets." Again, I believe
the document should specify how the PSK is derived.
[VC] I absolutely agree that derivation of PSK is critical. However, as stated
above, this draft specifies Diameter application only. Therefore, security
consideration section cannot include much more details on derivation of PSK as
it is specified elsewhere.
* Why "if nonces are included" where the document says that they *must* be
included (in the AVP occurrence table).
[VC] Good point. This is removed in v7.
Thanks,
Yaron
On 05/20/2011 04:50 PM, The IESG wrote:
The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server
to Diameter Server Interaction'
<draft-ietf-dime-ikev2-psk-diameter-06.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
theietf(_at_)ietf(_dot_)org mailing lists by 2011-06-03. Exceptionally,
comments may be sent toiesg(_at_)ietf(_dot_)org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
Abstract
The Internet Key Exchange protocol version 2 (IKEv2) is a component
of the IPsec architecture and is used to perform mutual
authentication as well as to establish and to maintain IPsec security
associations (SAs) between the respective parties. IKEv2 supports
several different authentication mechanisms, such as the Extensible
Authentication Protocol (EAP), certificates, and pre-shared secrets.
With [RFC5778] the Diameter interworking for Mobile IPv6 between the
Home Agent, as a Diameter client, and the Diameter server has been
specified. However, that specification focused on the usage of EAP
and did not include support for pre-shared secret based
authentication available with IKEv2. This document specifies IKEv2
server, as a Diameter client, to the Diameter server communication
for IKEv2 with pre-shared secret based authentication.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
IPsec mailing list
IPsec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|