[node req] Issue 34: security issues

[[e-mail]]

Assigned issue 34.


> >>For Section 8, RFCs 2401, 2402, and 2406 are currently being 
> >>revised by the IPsec group; that should be mentioned.
> 
> Ok. I agree that it is good to alert the reader to the
> fact that some of the documents may have updated RFCs
> available. Thanks.
> 
> >>The crypto algorithm requirements should be better aligned 
> >>with recommendations from the IPsec wg.  There's a draft that 
> >>lists 3DES as SHOULD, not MAY.
> 
> The problem is that the requirements have been aligned with
> the recommendations of the IPsec, as they exist in *RFCs*.
> Not drafts.
> 
> I personally think that we need to recommend and inform
> about better alternatives, even if such alternatives do not
> yet exist as RFCs or if they are not mandated by keywords.
> This is what we have done -- the document talks about 3DES,
> AES, etc.
> 
> However, there has been general resistance in the WG (maybe even the
> ADs) for us to mandate anything beyond the current normative RFCs. It
> was felt that the original RFCs should rather be updated than the
> node requirements document made to impose additional requirements.
> If the IESG thinks its okay for us to mandate stronger algorithms
> than what the current IPsec RFCs say, then I'm going to be
> *very* happy.
> 
> But if, not then I think its up to the IPsec WG to advance their
> documents and mandate the algorithms that they think are
> appropriate.
> 
> >>I think that IKEv? should be a SHOULD, not a MAY.  While the 
> >>IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will 
> >>soon and it describes automated key management as a "strong 
> >>SHOULD".  That's certainly the consensus in the security area.
> 
> This is also related to the question of what the current
> RFCs say. In the case of IKE, I'm actually uncertain what
> the keyword is -- it is not immediately clear to me from the
> document. Perhaps it is to others, I would appreciate comments
> on this! I think we should use a keyword that the current
> RFCs have, whatever that is.
> 
> Anyway, I think the node requirements document is somewhat
> different than a usual IETF protocol document. In the RFC for
> for protocol FOO, there are some security issues and those
> are solved with the support of some security mechanisms.
> 
> But here, the specific security issues appear within the
> RFCs that we refer to, and the necessary security mechanisms
> are introduced there as well. So when talking about FOO
> and IKE, we know that IKE addresses FOO's issues. But in
> the case of the node requirements document, the security
> issues either have been addressed in the relevant RFCs, or
> those RFCs should be reissued and corrected.
> 
> Additional stuff can be extremely useful for the nodes, but it
> may not address any IPv6-specific issue. For instance, if we
> required IKE, TLS, and S/MIME, this would make sure that
> those are available to the IPv6 nodes, but none of them would
> help addressing the security issues in, say, IPv6 ND.
> 
> So I guess what I am looking for is some guidance on whether
> this document should focus on the IPv6 specific part, or give
> a more general requirements. I think we need to choose between
> 
>   (1) "We, the IETF, think that in order to do IPv6, you
>       need <THIS>.", and
>   (2) "We, the IETF, think that in order to do IPv6, you
>       need <THIS> and the user on a node surely needs
>       also <THAT>."
> 
> I'm fine doing it either way, but we need to agree what
> the scope is.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------