Re: 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Detailed comments:
â The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March. â 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.
â 4.1: how can the incoming SPI be 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). â 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. â 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.
â How does key-lifetime relate to the lifetime of the IKE SA?
â 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. â 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. â Why "if nonces are included" where the document says that they *must* be included (in the AVP occurrence table).

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 the
ietf@xxxxxxxx mailing lists by 2011-06-03. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]