Subject: [Mip4] RE: [mobile-ip] Comments on 3012bis

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 31 Jul 2003 14:07:31 -0500

Hello Pete,

I have revised the terminology for the "previously used challenge" for
section 1.1 as below:

"previously used challenge: The challenge is previously used challenge if
the Mobile Node sent the same challenge to the Foreign Agent in a previous
Registration Request, and that previous Registration Request passed all
validity checks performed by the Foreign Agent. The Foreign Agent may not be
able to keep records for all previously used challenges, but see section 3.2
for minimal requirements."

I believe we won't be requiring terminology "stale challenge" since it is
not used anywhere else in the document. Also, there won't be any changes
required on current definition of "STALE_CHALLENGE".

Let me know if you have any comments/suggestions.

Regards,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2003 7:59 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]'
> Subject: RE: [mobile-ip] Comments on 3012bis
> 
> 
> 
> Hi, Jayshree,
> 
> The issue is that the text says you shall reject previously 
> used challenges (in all cases but retransmissions of valid 
> requests).  If "previously used" includes RRQs that weren't 
> validated, then it is possible for an attacker to use them up 
> before the MN can register.
> 
> -Pete
> 
> 
> Jayshree Bharatia writes:
>  > Pete,
>  > 
>  > I am not sure I understand your concern well. Can you 
> please clarify what  > risks are associated if the malicious 
> node consumes "previously used  > challenges". 
>  > 
>  > Thanks,
>  > Jayshree
>  > > -----Original Message-----
>  > > From: Pete McCann [mailto:[email-masked]] 
>  > > Sent: Friday, July 11, 2003 9:53 AM
>  > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
>  > > Cc: [email-masked]'; [email-masked]'; 
>  > > [email-masked]'
>  > > Subject: RE: [mobile-ip] Comments on 3012bis
>  > > 
>  > > 
>  > > 
>  > > Hi, Jayshree,
>  > > 
>  > > One point below...
>  > > 
>  > > Jayshree Bharatia writes:
>  > >  > > No, it is possible to reuse the challenge in a 
> retransmitted 
>  > >  > > registration request, as outlined in Section 3.2.  Under my 
>  > >  > > reading of that section a retransmission of a Challenge is 
>  > >  > > still a "previously used" challenge, even though the Reply 
>  > >  > > has not been sent/received.  Note that this is 
> different from 
>  > >  > > a "stale challenge" which is one that has been used in a 
>  > >  > > request, validated by the FA, and for which a Reply 
> was sent 
>  > >  > > to the MN.  I would like to keep this distinction in the 
>  > >  > > definitions.  Otherwise, I think you will need to re-write 
>  > >  > > some of the text in Section 3.2.
>  > >  > > 
>  > >  > [JB] I agree that the differentiation is based on whether 
>  > > the FA has sent  > corresponding Registration Reply to the MN 
>  > > or not. If the FA has already  > sent the reply, and the MN 
>  > > sends the same challenge in the new Registration  > Request, 
>  > > it will be "stale challenge". Otherwise, if it will be just  
>  > > > "previously used challenge". If we have agreement on this, 
>  > > I like to propose  > the following:  > 1. The new (proposed 
>  > > earlier) text will still be valid for the "stale  > 
>  > > challenge" terminology.  > 2. Add new definition called 
>  > > "previously used challenge" with the following  > description 
>  > > for section 1.1:  > "previously used challenge: Any challenge 
>  > > that has been used by the Mobile  > Node in the previous 
>  > > Registration Request"  > 
>  > >  > I notice that you have additional statement saying "and 
>  > > that previous  > Registration Request passed all checks prior 
>  > > to forwarding to the HA". I  > would rather not specify where 
>  > > exactly the Registration Request may be  > getting processed 
>  > > once it is received at the FA. It may be forwarded to AAA  > 
>  > > or HA. Also, even if it doesn't passes all checks, it is 
>  > > still considered as  > a "previously used challenge".
>  > > 
>  > > But I think this opens up a denial of service attack, where 
>  > > malicious nodes can consume challenges on behalf of other 
>  > > nodes on the same link.  If you don't at least check the 
>  > > MN-AAA or MN-FA authentication on the Challenge, you should 
>  > > not mark it as "previously used" for that mobile.  That's why 
>  > > I put the language about passing validity checks at the FA.  
>  > > This could be consultation of a AAA interface or verification 
>  > > of the MN-FA auth extension---I was intentionally vague 
> about that.  > > 
>  > > -Pete
> 
>

---

From: Pete McCann <[email-masked]>
Date: Thu, 31 Jul 2003 15:04:28 -0500

Hi, Jayshree,

I agree with the definition of "previously used challenge" you give
below, and I also agree the existing procedures for when to return
STALE_CHALLENGE should now be correct.

-Pete

Jayshree Bharatia writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2656.31">
 > <TITLE>RE: [mobile-ip] Comments on 3012bis</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Hello Pete,</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I have revised the terminology for the &quot;previously used challenge&quot; for section 1.1 as below:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&quot;previously used challenge: The challenge is previously used challenge if the Mobile Node sent the same challenge to the Foreign Agent in a previous Registration Request, and that previous Registration Request passed all validity checks performed by the Foreign Agent. The Foreign Agent may not be able to keep records for all previously used challenges, but see section 3.2 for minimal requirements.&quot;</FONT></P>
 > 
 > <P><FONT SIZE=2>I believe we won't be requiring terminology &quot;stale challenge&quot; since it is not used anywhere else in the document. Also, there won't be any changes required on current definition of &quot;STALE_CHALLENGE&quot;.</FONT></P>
 > 
 > <P><FONT SIZE=2>Let me know if you have any comments/suggestions.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Regards,</FONT>
 > <BR><FONT SIZE=2>Jayshree</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2>&gt; From: Pete McCann [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
 > <BR><FONT SIZE=2>&gt; Sent: Wednesday, July 16, 2003 7:59 AM</FONT>
 > <BR><FONT SIZE=2>&gt; To: Bharatia, Jayshree [RICH1:2H13:EXCH]</FONT>
 > <BR><FONT SIZE=2>&gt; Cc: [email-masked]'; [email-masked]'; </FONT>
 > <BR><FONT SIZE=2>&gt; [email-masked]'</FONT>
 > <BR><FONT SIZE=2>&gt; Subject: RE: [mobile-ip] Comments on 3012bis</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; Hi, Jayshree,</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; The issue is that the text says you shall reject previously </FONT>
 > <BR><FONT SIZE=2>&gt; used challenges (in all cases but retransmissions of valid </FONT>
 > <BR><FONT SIZE=2>&gt; requests).&nbsp; If &quot;previously used&quot; includes RRQs that weren't </FONT>
 > <BR><FONT SIZE=2>&gt; validated, then it is possible for an attacker to use them up </FONT>
 > <BR><FONT SIZE=2>&gt; before the MN can register.</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; -Pete</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; Jayshree Bharatia writes:</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; Pete,</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; I am not sure I understand your concern well. Can you </FONT>
 > <BR><FONT SIZE=2>&gt; please clarify what&nbsp; &gt; risks are associated if the malicious </FONT>
 > <BR><FONT SIZE=2>&gt; node consumes &quot;previously used&nbsp; &gt; challenges&quot;. </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; Thanks,</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; Jayshree</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; -----Original Message-----</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; From: Pete McCann [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Sent: Friday, July 11, 2003 9:53 AM</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; To: Bharatia, Jayshree [RICH1:2H13:EXCH]</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Cc: [email-masked]'; [email-masked]'; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; [email-masked]'</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Subject: RE: [mobile-ip] Comments on 3012bis</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Hi, Jayshree,</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; One point below...</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Jayshree Bharatia writes:</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; No, it is possible to reuse the challenge in a </FONT>
 > <BR><FONT SIZE=2>&gt; retransmitted </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; registration request, as outlined in Section 3.2.&nbsp; Under my </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; reading of that section a retransmission of a Challenge is </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; still a &quot;previously used&quot; challenge, even though the Reply </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; has not been sent/received.&nbsp; Note that this is </FONT>
 > <BR><FONT SIZE=2>&gt; different from </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; a &quot;stale challenge&quot; which is one that has been used in a </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; request, validated by the FA, and for which a Reply </FONT>
 > <BR><FONT SIZE=2>&gt; was sent </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; to the MN.&nbsp; I would like to keep this distinction in the </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; definitions.&nbsp; Otherwise, I think you will need to re-write </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; some of the text in Section 3.2.</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; [JB] I agree that the differentiation is based on whether </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; the FA has sent&nbsp; &gt; corresponding Registration Reply to the MN </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; or not. If the FA has already&nbsp; &gt; sent the reply, and the MN </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; sends the same challenge in the new Registration&nbsp; &gt; Request, </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; it will be &quot;stale challenge&quot;. Otherwise, if it will be just&nbsp; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; &gt; &quot;previously used challenge&quot;. If we have agreement on this, </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; I like to propose&nbsp; &gt; the following:&nbsp; &gt; 1. The new (proposed </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; earlier) text will still be valid for the &quot;stale&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; challenge&quot; terminology.&nbsp; &gt; 2. Add new definition called </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; &quot;previously used challenge&quot; with the following&nbsp; &gt; description </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; for section 1.1:&nbsp; &gt; &quot;previously used challenge: Any challenge </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; that has been used by the Mobile&nbsp; &gt; Node in the previous </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; Registration Request&quot;&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt;&nbsp; &gt; I notice that you have additional statement saying &quot;and </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; that previous&nbsp; &gt; Registration Request passed all checks prior </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; to forwarding to the HA&quot;. I&nbsp; &gt; would rather not specify where </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; exactly the Registration Request may be&nbsp; &gt; getting processed </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; once it is received at the FA. It may be forwarded to AAA&nbsp; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; or HA. Also, even if it doesn't passes all checks, it is </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; still considered as&nbsp; &gt; a &quot;previously used challenge&quot;.</FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; But I think this opens up a denial of service attack, where </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; malicious nodes can consume challenges on behalf of other </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; nodes on the same link.&nbsp; If you don't at least check the </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; MN-AAA or MN-FA authentication on the Challenge, you should </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; not mark it as &quot;previously used&quot; for that mobile.&nbsp; That's why </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; I put the language about passing validity checks at the FA.&nbsp; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; This could be consultation of a AAA interface or verification </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; of the MN-FA auth extension---I was intentionally vague </FONT>
 > <BR><FONT SIZE=2>&gt; about that.&nbsp; &gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt;&nbsp; &gt; &gt; -Pete</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>

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