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

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 7 May 2003 17:23:15 -0500

Hi Bjorn,

I see your point on using ID but I have concern regarding having two
different ways to calculate authenticator depending on whether MN has
co-located CoA or not.  

Is there any security risk you see if the challenge is used arbitrarily from
HA perspective? If this is the case, we may have to revise our decision on
supporting MN with co-located CoA.

Thanks,
Jayshree

> -----Original Message-----
> From: Bjorn Andersson [mailto:[email-masked]] 
> Sent: Wednesday, May 07, 2003 4:25 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] MIPv4: MN-AAA authenticator and challenges
> 
> 
> On Wed, May 07 2003, at 13:47:32 -0500, Jayshree Bharatia wrote:
> > I didn't see specific reason of your objection other than the fact 
> > that the MN with co-located CoA won't be using challenge-response 
> > protocol. Appreciate if you can further clarify on: why ID 
> generated 
> > by the MN is better compare to Challenge?
> 
> Because the ID field _is_ a challenge by the HA; it can't be 
> arbitrarily chosen.
> 
>   Bjorn
> 
> -- 
> Bjorn Andersson <[email-masked]>
> PGP id 5AFC144B
> Mobile +358 40 7723074
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 8 May 2003 10:11:19 -0500

> I wrote:
> > > 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 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.
> 
> On Thu, May 08 2003, at 08:56:55 -0500, Ahmad Muhanna wrote:
> > As you know, this is not valid for the original problem 
> RFC3012 tried 
> > to solve.
> 
> 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.
> 

How allowing the MN to choose its MN-FA Challenge would work when
we have an FA in the middlle. Did not you say the MN-FA Challenge is used
for replay protection?

What I meant here is that MN which are using an FA COA, will not be able
to generate the MN-FA Challenge here. Otherwise, the whole concept of replay
protection between the MN and the FA is gone!!!!

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 9 May 2003 07:55:09 -0500

> 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.
>

You are correct.
RFC3344 needs to change to reflect that at least one rather than exactly one
authorization-enabling
extension is allowed in RRQ.
I think we have discussed this on the mailing list sometime ago on another
thread.
My understanding is that there will be an RFC3344-bis coming!!

Regards,
Ahmad
 
> Regards
> /// Hasse