Subject: [Mipshop] Tim polk's comment on 4140bis

From: Hesham Soliman <[email-masked]>
Date: Fri, 09 May 2008 19:43:17 +1000

Hi Tim,

Thanks for the detailed comments. Some points of discussion below.

 (1) The document introduces the Mobility Anchor Point (MAP) into the
    mobile IPv6 architecture, but the requirements/assumptions regarding the
    relationship between the mobile node and the MAP are not clear enough.
    These assumptions/requirements have a number of implications for the
    protocols that should be stated.  In particular, there is an implication
    that the trust relationship is so limited that authentication as a group
    member is generally sufficient. For example, a MAP may authenticate a
    mobile node based on a certificate issued by a known CA, rather than the
    specific identity in the certificate.

=> If you are referring to authenticating a previously unknown identity by
simply making sure the identity can be verified since a trusted CA signed
the cert, then yes I agree.
Is your comment that this shold be stated? Or do you see any problem with
it? I'm fine with describing in the way you mention above.

    Similarly, the mobile node may
    authenticate the MAP based on a cert from a known CA, even though the
specific MAP was previously unknown.  (Examples from 11.1)  I believe   this
is okay, based on my understanding of the requirements, but I
    would feel more confident if the trust relationship was fleshed
    somewhere. 

=> I'm happy to add more detail to it but I'd appreciate if you could tell
me what kinds of detail you want to see. The specification explains that
there is no need for allocating addresses to "known" identities. This is the
only difference between this and the HA. So, I'm afraid that it seems to me
the relationship is pretty simple to add a lot of detail. But if you see
something I'm missing please suggest it.

    Note that this is confused somewhat by the discussion of "security
    relationship" between the mobile node and the MAP in section 11.
    "mutual authentication, integrity protection and protection against
    replay attack" are necessary features, not a relationship.

=> True, those refer to the messages not the identities.

    (2) Authentication and authorization are conceptually related but
    they are different.  Authentication is generally the precursor, where
    we determine another party's identity, and authorization follows based
    on that identitty.  Just because a party's identity has been
    authenticated does not mean they are authorized to access anything.

=> Sure, except in the case where nothing is needed to authorise someone
except for knowing their identity and being able to tie that identity to an
allocated resource (the RCoA). It's a bit like walking into a bar in the US,
if you're over age you can come in. All the MAP needs to know is an identity
that can be tied to the address in order to authenticate future messages.
There are no other authorisation steps.

    The examples cited above blur the lines between these steps.

=> Yes because there is very little authorisation needed in this protocol.

    Hopefully, 
    this will be addressed as a side effect of addressing (1), but please
    revise with an eye towards clarity on authentication vs. authorization.
=> ok.

    (3) The security considerations section focuses on the expected
    deployment architecture, but several alternatives are specified in the
    document.  Tehse should be addressed in teh security considerations
    as well - either to describe differences in teh security considerations
    or to state that they are unchanged.

=> There is no impact on the security from different deployment scenarios. I
can add that.

    For example, It is noted in the introduction that the mobile node can
operate in a nomadic manner (no permanent home address).  Section 6.5 notes
that the RCoA address can be used as the source address without a Home
   Address option.  In these kinds of cases, are there additional
constraints or limitations imposed on the trust relationship between the MAP
    and the mobile node?

=> No, none.

Hesham

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 10 May 2008 13:22:17 +1000

Hi Tim, 

> Yes, my comment is that this should be stated in the document.  I do
> not see
> any specific problem with it, but would like it clearly documented.

=> ok.

>> only difference between this and the HA.
> 
> Where is this difference first stated?  I did quick review of
> Sections 1, 2, and
> 3 (intro only), and found a number of references to  the MAP as the
> local HA,
> but the difference isn't really spelled out is out?

=> It's not in the intro because it's a security specific distinction. So it
was included in section 11.1. I quote the text below:

   However, because the RCoA is temporary and is not
   bound to a particular node, a mobile node does not have to initially
   (before the first binding update) prove that it owns its RCoA (unlike
   the requirement on home addresses in Mobile IPv6) when it establishes
   a Security Association with its MAP.  A MAP only needs to ensure that
   a BU for a particular RCoA was issued by the same mobile node that
   established the Security Association for that RCoA.

   The MAP does not need to have prior knowledge of the identity of the
   mobile node nor its Home Address.  As a result the SA between the
   mobile node and the MAP can be established using any key
   establishment protocols such as IKEv2.  A return routability test is
   not necessary.

> 
>> So, I'm afraid that it seems to me
> I am not looking for lots of detail, but I would like the document to
> clearly show
> that the MAP is simply binding the current LCoA to an RCoA, so that
> the HA
> binding (to the RCoA) does not need to change.  Given that, the MAP does
> not need to know the identity of the MN, but may(?) need to verify
> that the
> MN is a member of the supported community.

=> Is the above text suffieicnt or do you want me to add something to it?

> A little rewording is in order there, but I am not looking for any
> new material.

=> Ok.

> Unless I missed it (which is quite plausible), that is much clearer
> here than
> in the document.  That is the relationship issue I felt was missing.
> 
> With the relationship stated, all that we need to note is that
> authentication
> and authorization are essentially the same because the end goal is
> binding an identity with the RCoA.

=> Exactly, I'll try to make it clearer.

> That would be helpful.  One sentence would do.

=> ok.

Thanks,
Hesham

---

From: Tim Polk <[email-masked]>
Date: Fri, 9 May 2008 09:59:00 -0400

Hi Hesham,

Thanks, this was very helpful.  My comments are in-line..

> constraints or limitations imposed on the trust relationship  

Thanks for clearing that up.

> Hesham

Your responses have been very helpful to me.  I believe that very  
little is needed
to enable me to clear.

Please let me know if my responses are clear enough to work from.  
Resolving these
issues should not require any major surgery.  A few new sentences and  
perhaps a
paragraph or two should take care of it.  If it looks like new  
subsections are needed
I was not clear enough and you are working too hard!

Thanks,

Tim Polk