Subject: [Mip6] FW: secdir review request for mip6-bootstrapping-split

From: Basavaraj Patil <[email-masked]>
Date: Fri, 09 Jun 2006 09:32:11 +0300

Hello,

Below is a review by the Secdir on the Split scenario bootstrapping I-D.

-Chairs

------ Forwarded Message
> From: ext pat cain <[email-masked]>
> Date: Tue, 30 May 2006 20:54:38 -0400
> To: <[email-masked]>, 'Russ Housley' <[email-masked]>, 'Sam
> Hartman' <[email-masked]>
> Cc: 'Jari Arkko' <[email-masked]>, 'Basavaraj Patil'
> <[email-masked]>, 'ext Vijay Devarapalli'
> <[email-masked]>, 'Gopal Dommety' <[email-masked]>,
> 'James Kempf' <[email-masked]>, 'Giaretta Gerardo'
> <[email-masked]>
> Subject: RE: secdir review request for mip6-bootstrapping-split
> 
> Hi,
> 
> I did a special/out-of-cycle security review of:
> 
>> The MIP6 WG I-D: draft-ietf-mip6-bootstrapping-split-02.
>> URL:
>> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02.
> txt
>> 
> 
> Although the general idea presented in the document will work, I did not
> like the document. The document seems to be missing many specific details,
> pointing to other docs when magic is needed (e.g., "the detailed discussion
> is provided in [6]." There is no other discussion on the topic covered in
> [6], which is about IKE and MIPv6). Although I have read the document three
> times, I may still be missing something, but it seems like all the details
> are either in some other (draft or in-process) document or declared "out of
> scope" for this one.
> 
> For example, in section 3 there is a note that checking a certificate
> revocation list (called a 'CTL' here) is necessary, but nowhere in the
> document does it explain where all the parameters for this evaluation come
> from (Maybe a pointer to PKIX?).   Likewise, in section 5.2, IPSec Security
> Association Setup, there is no discussion of where the IPSec credentials
> come from (EAP?) -- just a document reference.  The document referenced
> assumes that credential info is already present in the MN, so the
> bootstrapping process seems a little magical. Yet there is significant
> detail explaining how to update the MN's DNS entry.
> 
> Maybe section 5.2 or a later section should show the flow of the AAA and/or
> IKE protocols to make sure that the necessary information as described in
> [6] is actually being found. Or fix the pictures of section 7 to actually
> show the steps before the IKE authentication magic. As the document
> currently envisions it, a mobile node (MN) uses EAP to authenticate to the
> service provider (MSP), then discovers its Home Agent (HA) IPaddress, then
> (magically) makes an IPSec security association with the HA via IKEv2.
> IKEv2 requires a bunch of numbers to do this work (like KEi). This being a
> bootstrapping document I expect that this section would have listed those
> and where the MN got them or made them up from. Do the security credentials
> come via the MSP->MN authentication process? How? [It's also possible that
> the MN would just use EAP with the HA to craft the IPSec SA key, but that
> scenario isn't discussed.]
> 
> 
> In section 9.3, security considerations, the ONE SENTENCE points to another
> document for the security of authentication issues. This being a
> bootstrapping document, I expect another sentence or maybe two sentences,
> discussing the major security issues with bootstrapping such as the
> impossibility of total authentication (since the MN will not have enough
> security information to perform all the authentication checks it has to
> declare a trust point to start from); how to trust that the HA and maybe the
> MSP are the correct entities to setup EAP/AAA/SA associations with (i.e.,
> how do I know that this device is my HA? Guessing wrong would be bad); and
> how a MN validates its self-generated keying material.
> 
> I think the idea expressed in the document is plausible, but as a
> bootstrapping document it needs the bootstrap info. And if you're going to
> mention certificates and CRLs, a pointer to the PKIX validation rules would
> be useful.
> 
> Pat Cain
> 
> 

------ End of Forwarded Message

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6