Subject: Re: [Mip6] FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 May 2006 14:57:56 -0700

Gerardo Giaretta wrote:
> Hi Sam,
> 
> thanks for the comments and sorry for very late answers.
> 
> Concerning the EAP issue, I think that both solutions that are under
> definition in the WG does not follow the directions you mentioned.
> After your and others' comments (also during ICOS BOF and HOAKEY BOF)
> the WG has been producing solutions where network access
> authentication and mobility service authentication are considered
> fully separated. It seems to me that this problem statement does not
> suggest this kind of solutions. Please let me know if you think some
> clarifying text needs to be added to this problem statement.
> 
> Concerning rfc4285, the WG is currently not working on a solutions for
> bootstrapping rfc4285 SAs. I'm OK with removing all references to
> rfc4285. Is this your suggestion?

couple of contexts where RFC 4285 is mentioned are
okay. RFC 4285 is mentioned as a mechanism for
securing the BU. thats is fine. we could say it
exists, but this problem statement does not address
4285 bootstrapping. completely ignoring it would
be a bad idea.

Vijay

> 
>> Comment:
>> The claim in section 5.2.1 that use of certificates would require
>> deploying a PKI is false.  I do agree that certificates do not align
>> well with AAA. I'd recommend rewording as "Certificates are not easily
>> supported by traditional AAA infrastructures."
>>
> 
> Done.
> 
> --Gerardo
> 
>> -----Original Message-----
>> From: Basavaraj Patil [mailto:[email-masked]]
>> Sent: mercoledì 1 marzo 2006 22.16
>> To: [email-masked]
>> Subject: [Mip6] FW: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps
>>
>>
>> FYI,
>>
>> ------ Forwarded Message
>> > From: ext Sam Hartman <[email-masked]>
>> > Date: Wed, 01 Mar 2006 16:03:22 -0500
>> > To: <[email-masked]>
>> > Cc: <[email-masked]>, <[email-masked]>
>> > Subject: DISCUSS and COMMENT: draft-ietf-mip6-bootstrap-ps
>> >
>> > Discuss:
>> > First, thanks for a good job on a well written problem
>> statement.  My
>> > concerns here are concernes about the document but can be
>> interpreted
>> > as early warnings about the direction the WG seems to be taking.
>> > Addressing the concerns against the document can probably
>> be done very
>> > simply, but it is important to discuss the working group's direction
>> > now to make sure that you will not end up with a discuss challenging
>> > something fundamental about your solution when it comes to the IESG.
>> >
>> > In section 7.2 you discuss using the authentication to both set up
>> > network access and mobility access.  I don't think this is
>> compatible
>> > with how the EAP working group and security area invision EAP being
>> > used. For example the key management framework requires
>> that all keys
>> > based on the EMSK be generated at the beginning of the
>> exchange. We've
>> > explicitly resisted several attempts to use EAP keying information
>> > used to set up network access to later generate keys for other
>> > purposes.  Both mobility and network access are at least valid EAP
>> > applications.  I recommend that you note that the question
>> of whether
>> > this authentication can be reused is open in your document.  I
>> > recommend that you get together with Russ Housley, Jari,
>> myself and the EAP
>> > community and decide whether this use is OK before designing a
>> > solution that assumes you will be able to do this.
>> >
>> > I'm assuming that this problem statement is for a standards track
>> > solution.  As such, I don't think considering RFC 4285 is
>> appropriate.
>> > In particular I don't think it makes sense for us to base standards
>> > trackrequirements on a protocol we were unwilling to
>> standardize.  It
>> > feels too much like using the informational RFC series as a
>> mechanism
>> > for doing ongoing standards work without meeting our
>> requirements for
>> > review.  If the working group believes that something like
>> RFC 4285 is
>> > needed, then the working group should commit to doing the necessary
>> > work to make a standard in this space: write a service model for
>> > Mobile IP security and then write both the authentication
>> protocol and
>> > the IPsec security solution as architectural blocks that fit that
>> > model.  If the working group does not want to do this work, then RFC
>> > 4285-like solutions need not influence requirements here.
>> >
>> > Comment:
>> > The claim in section 5.2.1 that use of certificates would require
>> > deploying a PKI is false.  I do agree that certificates do not align
>> > well with AAA. I'd recommend rewording as "Certificates are
>> not easily
>> > supported by traditional AAA infrastructures."
>> >
>>
>> ------ End of Forwarded Message
>>
>>
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
>>
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

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

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 2 May 2006 10:17:28 +0200

Hi Sam,

sorry for that. It's my fault.

Find the email below.

--Gerardo

On 5/2/06, Sam Hartman <[email-masked]> wrote:
> Hi.  I don't seem to have the original mail to which this is a reply.
>
>

--------------------------------------------------------------

Hi Sam,

Done.

--Gerardo

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 2 May 2006 17:57:44 +0200

On 5/2/06, Sam Hartman <[email-masked]> wrote:
> >>>>> "Gerardo" == Gerardo Giaretta <[email-masked]> writes:
>
>
>     Gerardo> Hi Sam,
>
>     Gerardo> thanks for the comments and sorry for very late answers.
>
>     Gerardo> Concerning the EAP issue, I think that both solutions
>     Gerardo> that are under definition in the WG does not follow the
>     Gerardo> directions you mentioned.  After your and others'
>     Gerardo> comments (also during ICOS BOF and HOAKEY BOF) the WG has
>     Gerardo> been producing solutions where network access
>     Gerardo> authentication and mobility service authentication are
>     Gerardo> considered fully separated. It seems to me that this
>     Gerardo> problem statement does not suggest this kind of
>     Gerardo> solutions. Please let me know if you think some
>     Gerardo> clarifying text needs to be added to this problem
>     Gerardo> statement.
>
> Take a look at the last phrase in the following paragraph of 7.2:
>
>     In this scenario, the ASA and MSA are the same entity.  The MN has
>        security credentials for access to the network and these credentials
>           can be used to bootstrap MIPv6.  This bootstrapping can be done
>              during the same phase as access authentication/authorization or at a
>                 later time (probably based on some state created during access
>                    authentication/authorization).
>
> It sounds like the two are bound.
>

I would delete the last sentence. I would like to keep the following:

>     In this scenario, the ASA and MSA are the same entity.  The MN has
>        security credentials for access to the network and these credentials
>           can be used to bootstrap MIPv6.

since it is a clear deployment scenario. Sounds good?

>     Gerardo> Concerning rfc4285, the WG is currently not working on a
>     Gerardo> solutions for bootstrapping rfc4285 SAs. I'm OK with
>     Gerardo> removing all references to rfc4285. Is this your
>     Gerardo> suggestion?
>
> I'd certainly be happiest with that.
>
> I do think that  the mention of RFC 4285  in the following bullet should be removed:
>
>        *  IPsec SA between MN and HA, IKE pre-shared secret between MN
>            and HA, or shared secret/security association for
>                 authentication protocol [RFC4285]
>
> I don't have a problem with the reference to 4285 in section 1.
>

I'm OK with that. What do others think?

--Gerardo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 May 2006 23:02:27 +0300

> I would delete the last sentence. I would like to keep the following:

Ok.

> since it is a clear deployment scenario. Sounds good?

Ok. Maybe "... can also be used ... ".

> I'm OK with that. What do others think?

Ok for me.

--Jari