Subject: RE: [mobile-ip] MIPv4: MN-AAA authenticator and challenges

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 8 May 2003 08:56:55 -0500

> Subject: Re: [mobile-ip] MIPv4: MN-AAA authenticator and challenges
> 
> 
> 
> The point is, why do we need to append LS237B(FA-chal) in 
> CHAP_challenge? It would work equally well with RADIUS 
> servers not aware of MIP if the CHAP_challenge was only 
> MD5(MipMsgAbove). The mobile would thus compute 
> "MD5(MSB(FA-chal) + Key + MD5(MipMsgAbove))". Since "MipMsgAbove" 
> contains FA-chal we have fulfilled the replay protection need. 
> 
> Let's assume that CHAP_challenge was only MD5(MipMsgAbove).  
> Again, I am no security expert, but to my understanding MD5 
> has its weeknesses which would make it possible to insert 
> data in MipMsgAbove (e.g. in the form of a skippable 
> extension), so that you can effectively choose CHAP_challenge 
> yourself. Appending LS237B(FA-chal) to CHAP_challenge makes 
> it a lot harder to choose the CHAP_challenge yourself. This

I disagree. 
Is this referenced any where?

> was also what Pete McCann <[email-masked]> replied in 
> Message-ID <[email-masked]> to 
> my question:
> 
> 	Using only the MD5 sum of the request (which normally includes
> 	the Challenge) would have been a possibility, but perhaps
> 	one could argue that by repeating the actual value of the
> 	Challenge and including it in the response we can further
> 	reduce the impact of potential hash collisions.
> 
> If the MN can generate FA-chal itself (as suggested for an MN 
> with a co-located address), then it can generate 
> CHAP_challenge itself and we're back to square one. In the 

I do not understand this one. 
The strength of the whole issue here is the secret key between the MN and
AAA. 
Everything else in transmitted on the clear. I do not see any difference
using 
MD5 with a random number the MN generates or it receives from FA or any
other agent. 
I think the added value here is very close to zero.

> case for timestamps, the ID field can only be selected from a 
> limited number of identifiers in way so that the HA accepts 
> it, and in the case for nonces there is exactly one valid ID 
> field. As you know, the purpose of the ID field is to prevent 
> replay protection, just to way the FA-challenge's purpose is 
> to prevent replay protection. The ID field is "in control" 

BUT we are not discussing the replay protection here. There is already
a mechanism between the MN with co-located care of address and its HA.
Using the MN-FA challenge here is for simplicity and consistency with
what already out there as far as AAA infrastructure and the RFC at hand.
Let us not forget that challenge was supposed to serve replay protection
between the MN and its FA. which to some extent does not exist in the case
of MN with co-located care-of-address. OR we may say the MN is working as 
its own FA; If you would.
HA is not going to use this MN-FA challenge for replay protection; right?

> partially by the HA and partially by the MN, effectively 
> making it the HA's challenge to the MN and vice versa.
> 
> If we allow the MN to select FA-challenge itself, then we 
> should admit that we could have left out LS237B(FA-chal) from 
> CHAP_challenge to begin with. If LS237B(FA-chal) was not in 
> CHAP_challenge we wouldn't be having this discussion.
>

As you know, this is not valid for the original problem RFC3012 tried to
solve.

Regards,
Ahmad

> To make it clear, I am not stating that I am correct, I'm 
> just stating my view of the situation. I'm open to discussion 
> and explanations.
> 
>   Bjorn
> 
> -- 
> Bjorn Andersson <[email-masked]>
> PGP id 5AFC144B
> Mobile +358 40 7723074
>

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 8 May 2003 17:16:46 +0300

> As you know, this is not valid for the original problem RFC3012 tried to

No I don't know. My point was exactly that it is valid. See also the
text above I quoted from Pete McCann's response.

  Bjorn

---

From: Hans Sjostrand <[email-masked]>
Date: Thu, 08 May 2003 17:49:15 +0200

Ahmad Muhanna wrote:
  [zip]
> As you know, this is not valid for the original problem RFC3012 tried to 

Could someone make a brief tutorial for us that aren't in 3GPP2 why we 
do all this fuzz at all. Cause I don't understand. The messages between 
the MN and the HA is autenticated with the MN-HA SA. Why do we try to 
squize in 2 extra extensions with some kind of fake challanges in order 
to have some additional AAA authentication in the home network.

If we anyway choose to do this I guess this have to update in RFC3344, 
section 3.8.2.1. Validity Checks

<..> if more than one authorization-enabling extension is found <..> the 
home agent MUST reject the mobile node's registration and SHOULD send a 
Registration Reply to the mobile node with Code 131.  The home agent 
MUST then discard the Request and SHOULD log the error as a security 
exception.

Regards
/// Hasse

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 8 May 2003 20:52:34 +0300

> to have some additional AAA authentication in the home network.

I don't think this is only about 3GPP2. The MN may not have an SA with
the HA, e.g. if the HA is dynamically allocated. If the HA has an SA
with AAA and the MN with AAA, then there is a transitive trust between
the HA and MN.

> MUST then discard the Request and SHOULD log the error as a security 

Yes, and I believe that are other errers in the RFC that have been
introduced since the MN-AAA authenticator came into the picture. I think
most errors are more or less text that has not been updated rather than
real problems.

  Bjorn