Subject: Re: [HOKEY] draft-ietf-hokey-erx-04 - Revision and Fixes to Issues from Tracker

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 06 Sep 2007 16:34:11 -0700

Hi Glen, Charles,

Do you want us to fix the rIK length issue now or wait and do it as part 
of the WGLC?  Are there any pending issues before issuing an LC on this 
document?

thanks,
Lakshminath

On 8/24/2007 6:26 PM, Narayanan, Vidya wrote:
> All,
> The updated draft can be found at
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txt.  The
> authors believe that this revision captures all the issues that need to
> be addressed based on the issues tracker (status detailed below) and
> that the document is ready for WGLC.  Assuming the chairs believe that
> the issues have been resolved satisfactorily, we request them to issue a
> last call on the document. 
> 
> Thanks,
> Vidya
> 
> Here is a status on the issues from the issues tracker: 
> 
> ------------------------
> 
> Issue 4: ERX: channel binding support needed  
> 
> Resolved in the earlier version
> 
> ------------------------
> 
> Issue 5: ERX: initial HOKEY message            
> 
> Resolved - added EAP Initiate Re-auth-Start message for authenticator
> initiation
> 
> ------------------------
> 
> Issue 17: ERX: ERX in the title                     
> 
> Resolved - changed title to "EAP Extensions for EAP Re-authentication
> Protocol (ERP)" to include ERP in the title
> 
> ------------------------
> 
> Issue 16: ERX: terminology issues                  
> 
> There was no consensus on changing the terms. Hence, no changes have
> been done in this revision. 
> 
> ------------------------
> 
> Issue 15: ERX: bootstrapping possibly broken   
> 
> No technical issues with ERP bootstrapping were noted.  We are not
> suggesting any changes to the EAP behavior or use of the MSK produced by
> EAP - hence, any restrictions/changes to the use of the MSK is
> inappropriate for this document.  Hence, no changes are needed here. 
> 
> ------------------------
> 
> Issue 19: ERX: location of integrity key          
> 
> The use of rIK for the ERP exchange itself is appropriate, since it uses
> an integrity key that is produced for the context of re-authentication.
> If the re-authentication functions were performed by an entity other
> than the EAP server (EMSK holder), this produces no dependencies on any
> key outside the re-authentication key hierarchy.  Hence, no changes are
> needed here. 
> 
> ------------------------
> 
> Issue 20: ERX: preauth text                        
> 
> Resolved
> 
> ------------------------
> 
> Issue 18: ERX: editorial changes                   
> 
> Resolved
> 
> ------------------------
> 
> Issue 21: ERX: rMSK derivation id/seq          
> 
> Cryptographically, the necessary separation across rMSKs is provided by
> the sequence number.  The EAP methods do not use any authenticator IDs
> in the MSK generation as well.  So, there is no need to include
> identities in the rMSK generation either.  Channel binding support is
> provided in ERP and that can be used to assert identities when needed.
> The lower layer may choose to include the appropriate identities in the
> TSK generation (as some lower layers already do). 
> 
> ------------------------
> 
> Issue 22: ERX: key transport and refs to key mgt doc 
> 
> Open issue; not sure what the reference would be needed for. 
> 
> ------------------------
> 
> Issue 23: ERX: root key -- USRK or DSUSRK?    
> 
> Subsequent consensus is not to derive DSUSRKs from USRKs.  Hence, this
> issue is no longer valid. 
> 
> ------------------------
> 
> Issue 32: ERX: transport protocol                 
> 
> Subsequent to the discussion at IETF69, this no longer seems to be an
> issue. 
> 
> ------------------------
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
> 

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 06 Sep 2007 16:35:50 -0700

Sending to Glen's correct address this time.

Sorry about that.

regards,
Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Mon, 10 Sep 2007 06:50:57 -0400

Thanks for putting together the revision.  I've updated the tracker with 
the changes indicated below.  The document authors felt that the 
following issues were non-issues:

* ERX: bootstrapping possibly broken
   http://www.ltsnet.net:8080/hokey/issue15

* ERX: terminology issues
   http://www.ltsnet.net:8080/hokey/issue16

* ERX: location of integrity key
   http://www.ltsnet.net:8080/hokey/issue19

* ERX: rMSK derivation id/seq
   http://www.ltsnet.net:8080/hokey/issue21

* ERX: key transport and refs to key mgt doc
   http://www.ltsnet.net:8080/hokey/issue22

* ERX: root key -- USRK or DSUSRK?
   http://www.ltsnet.net:8080/hokey/issue23

There hasn't been any subsequent conversation on the list.  If you 
disagree, please post your comments to the list by September 20, 
otherwise we'll close the issues and proceed to WGLC.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Sep 2007 18:18:39 -0400

I have two comments on erx-04.

[1] Regarding Issue 15, I saw text (quoted below) on re-authentication
DoS in Security Considerations, which is a good thing.  However, I am
wondering if the suggested mitigation method is creating another
problem.

"
   In addition, a denial of service attack may be possible using the EAP
   Iniaite/Re-auth message.  The attacker sends a bogus EAP Initiate Re-
   auth message, which may be carried by the authenticator in a RADIUS-
   Access-Challenge to the server; in response to that the server may
   send a RADIUS- Access-Reject.  Note that such attacks may be
   plausible with the EAP-Start capability of 802.11 and other similar
   facilities in other link layers and where the peer can initiate EAP
   authentication; an attacker may use such message to start an EAP
   method run, which fails and may result in the server sending a
   RADIUS-Access-Reject message.  To mitigate the impact of such DoS
   attacks, the authenticator must not tear down any link layer
   connections as long as there is at least one active MSK and an active
   RADIUS session (e.g., lifetime has not expired).  It appears that
   some implementations at the time of this writing already employ such
   mitigation techniques.
"

If the authenticator does not tear down link-layer connections when
re-authentication fails when there is at least one active MSK and an
active RADIUS session, what is the purpose of performing
re-authentication?  In my understanding, re-authentication is
performed to modify authorization-related attributes including
authorization lifetime.  In the current practice as far as I know, if
re-authentication fails, authorization state including link-layer
sessions is deleted, and there is nothing wrong with it.  

However, the text seems to suggest changing the current practice *just
to deal with re-authentication DoS attack for ERX bootstrapping*.
Note that re-authentication DoS attack in general can be mitigated by
simply not allowing immediate re-authentication at the link layer.
Since requiring this specific mitigation can significantly affect the
current AAA deployment, I don't think it's reasonable to require or
recommend this specific mitigation technique.

[2] Regarding Issue 22, erx draft should contain a normative reference
to draft-ietf-hokey-key-mgm-00.txt with indicating that the key
distribution mechanism is specified in the key-mgm draft.  Otherwise,
what is the purpose of the key-mgm draft?

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 19 Sep 2007 16:21:29 -0700

Yoshi,

Thanks for your comments.  Please see inline:

On 9/19/2007 3:18 PM, Yoshihiro Ohba wrote:
> re-authentication?  

In the above case, there was no re-authentication.  There was a bogus 
message sent by an adversary which the RADIUS server recognizes as bogus.

> In my understanding, re-authentication is

As Glen noted at the Chicago meeting, this is not new.

Furthermore, the attack is plausible with plain old EAP.

> recommend this specific mitigation technique.

We can say that the technique is recommended, if that is the consensus.

> what is the purpose of the key-mgm draft?

What do we need to refer to in that document?  I couldn't find anything 
and hence there is no need for normative reference.  An informative 
reference can be associated with a nod to the other work and the 
relative positioning.

best,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Sep 2007 05:23:30 -0400

> message sent by an adversary which the RADIUS server recognizes as bogus.

Not necessarily.  In general, a re-authentication failure could happen
without a DoS attack by a legitimate peer which used invalid
credentials due to, e.g., password mistyping.  It is difficult to tell
whether a particular re-authentication is under a DoS attack or a just
an errneous case.

> Furthermore, the attack is plausible with plain old EAP.

I agree that the attack itself is not new, but the suggested
mitigation technique to the attack seems just wrong.  I can show an
analogy here.  In IKEv2, when rekeying an IKE_SA fails, the IKE_SA and
any associated CHILD_SAs must be closed.  If the IKE_SA associated
CHILD_SAs are not closed when the rekeying fails, then there will be
an uncertain time period in which the authenticity of the initiator is
lost but the SAs still exist, which does not show a good security
property.

> We can say that the technique is recommended, if that is the consensus.

I don't agree with that the technique is recommended as I explained
above.

> reference can be associated with a nod to the other work and the 

My comment is based on the fact that ERX has a dependency on a key
distribution mechanism for its deployment.  It is not possible to
implement ERX without implementing a key distribution mechanism.  The
key distribution mechanism is specified in key-mgm draft.  So key-mgm
draft has to be a normative reference.  There is text (quoted below)
about key distribution, but I think this text is too ambiguous to
implement (and this is what Issue 22 is talking about, right?)

"The rMSK is transported in a manner similar to the MSK transport
along with the EAP Success message in a regular EAP exchange."

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Sep 2007 08:59:09 -0700

Yoshi,

The text in 4306 says: "If an SA
    has expired or is about to expire and rekeying attempts using the
    mechanisms described here fail, an implementation MUST close the
    IKE_SA and any associated CHILD_SAs and then MAY start new ones."

The keyword being "attempts" and the intention being to cover the case 
of no responses from the peer and legitimate failures.  Consider that 
the CREATE_CHILD_SA looks like this:  HDR, SK {IDi, [CERT,] [CERTREQ,] 
[IDr,]
                   AUTH, SAi2, TSi, TSr}

Are you saying that sending a legitimate HDR followed by some garbage 
will close an IKE SA?  It is definitely not the case.

 From my point of view, the above issue is closed now.

On rMSK transport, our intern found that the guidance available now is 
sufficient (and that implementation was done in open source code).  The 
MSK is now transported in an interoperable fashion now and the rMSK can 
follow the same guidelines.

In fact, changing that is a non-starter in many cases.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Sep 2007 09:27:30 -0700

> whether a particular re-authentication is under a DoS attack or a just

Following up on this, first, there is no user interaction in case of 
ERP; no typing of passwords etc.  One possibility of errors is this: the 
MAC can be verified (i.e., legitimate peer has sent the message), but 
there is a policy mismatch or say payload malformation.  In such cases, 
the server can indicate the error/mismatch and let the peer try again. 
If such retries fail, say after 3 attempts, I can see the point of 
closing the connection including the original connection (if we are to 
follow the IKEv2 model; not that it is necessary, but I can appreciate 
that).  I will make another point here, IKEv2 relies on these kinds of 
failure indications for dead peer detection.  In our case, repeated 
retries to do ERP may fail, but the original connection can go on.  In 
that case, I don't see the need to follow the IKEv2 model.  We have 
lifetimes; IKEv2 does not.

In all other cases (other than being able to verify that the legitimate 
peer has indeed sent the message), we will be facilitating DoS attacks 
if we follow your proposal, in that a DoS attack succeeds because the 
system is prone to shutdown so easily.  That would be bad design.

best regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Sep 2007 12:55:28 -0400

Lakshminath,

> will close an IKE SA?  It is definitely not the case.

In the above case, the garbage message will be discarded without
closing the SA because the message is received over an existing SA.
However, the ERX bootstrapping case is different from this case in
that the ERX bootstrapping exchange may not be protected by an
existing SA.

I think that a better remedy for this problem is to recommend lower
layers and AAA protocols to support "proactive rekeying" in which two
SAs can exist in a short amount of time to allow smooth migration from
one SA to another during rekey.  IKEv2 has this property which is
seems nice.

> follow the same guidelines.

I don't understand this.  What exact key distribution mechanism was
implemented?  I am asking because I did not see any consensus on key
transport security protocol yet.

Regards,
Yoshihiro Ohba

> >>>>Thanks for putting together the revision.  I've updated the tracker 
> >>>>with the changes indicated below.  The document authors felt that the 
> >>>>>Do you want us to fix the rIK length issue now or wait and do it as 
> >>>>>part of the WGLC?  Are there any pending issues before issuing an LC 
> >>>>>on this document?
> >>>>>
> >>>>>thanks,
> >>>>>Lakshminath
> >>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Sep 2007 13:23:04 -0400

> ERP; no typing of passwords etc.  One possibility of errors is this: the 

The pass-through authenticator should not have to know about which EAP
method is running on top of EAP.  Note that (re-)authentication can
happen with any EAP method including password-based ones.

> that).  

Such retries, if any, should happen within the EAP method, not at the
lower layers.  There is no need for lower layers to keep the original
connection when authentication fails for whatever reasons, rather it's
dangerous.

> I will make another point here, IKEv2 relies on these kinds of 

I don't get your point here.  Why does re-authentication DoS attack
issue have to do with dead peer detection?

> system is prone to shutdown so easily.  That would be bad design.

In my original proposal (i.e., use of EAP-EXT for boootstrapping ERX),
a DoS attack will not succeed if the lower layer simply rejects
re-authentication attempts for a certain amount of time after the
initial authentication.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Sep 2007 10:43:06 -0700

Yoshi,

Thanks again.  Please propose text and we can review whether we get any 
better guarantees and functionality.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 20 Sep 2007 10:45:21 -0700

> transport security protocol yet.

"rMSK transport is identical to that of MSK transport" in my view is 
necessary and sufficient.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Sep 2007 14:31:15 -0400

> necessary and sufficient.

This assumes that the key distribution mechanism used for MSK is the
concensus of the HOKEY WG for distributing keys derived from EMSK.  I
don't agree with it.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Sep 2007 18:00:34 -0400

> better guarantees and functionality.

I will send the text.

Thank you,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Fri, 21 Sep 2007 11:34:32 +0300

Hi:

Inline pl.

Preeti

>-----Original Message-----
>From: ext Yoshihiro Ohba [mailto:[email-masked]] 
>Sent: 20 September, 2007 21:31
>To: Lakshminath Dondeti
>Cc: [email-masked]
>Subject: Re: [HOKEY] draft-ietf-hokey-erx-04 - Revision and 
>Fixes to Issuesfrom Tracker
>
>> >>On rMSK transport, our intern found that the guidance 
>available now 
>> >>is sufficient (and that implementation was done in open source 
>> >>code).  The MSK is now transported in an interoperable fashion now 
>> >>and the rMSK can follow the same guidelines.
>> >
>This assumes that the key distribution mechanism used for MSK 
>is the concensus of the HOKEY WG for distributing keys derived 
>from EMSK.  I don't agree with it.

[Preeti] I agree with Yoshi here. This is the reason why I was asking
Problem statement draft to provide some explanation about the key
distribution.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Sep 2007 09:50:38 -0700

> Problem statement draft to provide some explanation about the key

Do you agree that rMSK is equivalent to the MSK?

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 24 Sep 2007 10:15:01 -0400

Here is my suggestion.

Change the current text in Security Consideration section:

"

to:

"
   In addition, a denial of service attack may be possible using the
   EAP Initiate/Re-auth message.  The attacker sends a bogus EAP
   Initiate Re-auth message, which may be carried by the authenticator
   in a RADIUS-Access-Challenge to the server; in response to that the
   server may send a RADIUS- Access-Reject.  Note that such attacks
   may be plausible with the EAP-Start capability of 802.11 and other
   similar facilities in other link layers and where the peer can
   initiate EAP authentication; an attacker may use such message to
   start an EAP method run, which fails and may result in the server
   sending a RADIUS-Access-Reject message and thus the link layer
   connections being terminated.  To prevent such DoS attacks, it is
   RECOMMENDED that lower layers and AAA protocols define a mechanism
   to support proactive rekeying [RFC4306] in which two link layer SAs
   derived from different EAP keying materials for the same peer can
   exist in a short amount of time so that smooth migration from the
   current link layer SA to the new one is possible during rekey.
   Such a proactive rekeying mechanism prevents the link layer
   connections from being terminated when a re-authentication
   procedure fails due to the bogus EAP Initiate Re-auth message.
"

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 24 Sep 2007 17:19:00 -0700

Yoshi,

Many thanks for providing the text.  I have a couple of comments; let me 
suggest revisions to your text and explain the reasoning.

 > To prevent such DoS attacks, it is
 >    RECOMMENDED that lower layers define mechanisms
 >    to support two link layers SAs (TSK SAs)
 >    exist for a short amount of time so that smooth migration from a
 >    Such mechanisms prevent the link layer

I would like us to not introduce new terminology "proactive rekeying" to 
avoid any confusion.  Further, based on the rest of the text it appears 
that no changes to AAA protocols are needed.

If you are ok with the compromise text above, if the group has no 
objections, I am ok with including it.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 24 Sep 2007 22:26:20 -0400

Lakshminath,

- I agree that not using the new terminology is better.

- I believe that some change to AAA protocols is needed.  Otherwise,
there will be state inconsistency between NAS and AAA server when the
NAS receives RADIUS-Access-Reject or equivalent for the new link layer
SA.  Without changing the AAA protocols, there would be no way for the
AAA server to distinguish the AAA exchanges associated with each of
the two link layer SAs (i.e., the current and new ones).  This means
that the only thing the legacy AAA server can do is to just shutdown
the existing authorization state for the peer entirely, while the NAS
will still try to maintain its authorization state associated with the
current link layer SA.  My analysis here is coming from an analogy
that the combination of pass-through EAP authenticator and EAP server
is considered as "distributed IKEv2 responder" and thus there must be
some way to distinguish the two SAs within the distributed responder
function.  For the same reason, I believe that so called proactive
rekeying in IKEv2 is not possible with EAP over IKEv2 where both the
current and new IKE_SAs are established using EAP with the use of
legacy AAA protocols in the backend.

Best Regards,
Yoshihiro Ohba

On Mon, Sep 24, 2007 at 05:19:00PM -0700, Lakshminath Dondeti wrote:
> >>>>>>What do we need to refer to in that document?  I couldn't find 
> >>>>>>anything and hence there is no need for normative reference.  An 
> >>>>>>informative reference can be associated with a nod to the other work 
> >>>>>>and the relative positioning.
> >>>>>>>>with the changes indicated below.  The document authors felt that 
> >>>>>>>>the following issues were non-issues:
> >>>>>>>>
> >>>>>>>>>Do you want us to fix the rIK length issue now or wait and do it 
> >>>>>>>>>as part of the WGLC?  Are there any pending issues before issuing 
> >>>>>>>>>an LC on this document?
> >>>>>>>>>
> >>>>>>>>>thanks,
> >>>>>>>>>Lakshminath
> >>>>>>>>>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 11:55:46 -0700

Hi Yoshi,
A few comments/questions inline.  

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 7:26 PM
> To: Dondeti, Lakshminath
> Cc: [email-masked]
> - I believe that some change to AAA protocols is needed.  
> Otherwise, there will be state inconsistency between NAS and 
> AAA server when the NAS receives RADIUS-Access-Reject or 
> equivalent for the new link layer SA.  Without changing the 
> AAA protocols, there would be no way for the AAA server to 
> distinguish the AAA exchanges associated with each of the two 
> link layer SAs (i.e., the current and new ones).  

The above seems to indicate that the AAA server somehow knows anything
about a link layer SA, even when there is just one of that.  I don't see
why the AAA server would need to know anything about the link-layer SA.
Also, at the NAS, the EAP authenticator and backend (AAA client) state
machines are closely tied and hence, I don't believe that the NAS
deletes all the state associated with the peer upon receiving the
Reject.  It should only delete state corresponding to that EAP session. 

>This means 
> that the only thing the legacy AAA server can do is to just 
> shutdown the existing authorization state for the peer 
> entirely, while the NAS will still try to maintain its 
> authorization state associated with the current link layer 
> SA.  

This doesn't make sense to me either.  If this is a concern, for
whatever reason, we can say that an ERP failure must not delete valid
EAP state at the AAA server and the server will have the option of
running a full EAP if ERP happens to fail too often. 

> My analysis here is coming from an analogy that the 
> combination of pass-through EAP authenticator and EAP server 
> is considered as "distributed IKEv2 responder" and thus there 
> must be some way to distinguish the two SAs within the 
> distributed responder function.  For the same reason, I 
> believe that so called proactive rekeying in IKEv2 is not 
> possible with EAP over IKEv2 where both the current and new 
> IKE_SAs are established using EAP with the use of legacy AAA 
> protocols in the backend.
> 

I am lost on the text above.  I don't know if you are saying that IKEv2
today cannot proactively rekey SAs while using EAP, which would actually
imply that RFC4306 is broken... In any event, let's focus on the
previous couple of points; the IKEv2 analogy is probably not relevant
for this discussion. 

Thanks,
Vidya

> > Many thanks for providing the text.  I have a couple of 
> comments; let 
> > me suggest revisions to your text and explain the reasoning.
> > 
> > I would like us to not introduce new terminology "proactive 
> rekeying" 
> > to avoid any confusion.  Further, based on the rest of the text it 
> > appears that no changes to AAA protocols are needed.
> > 
> > >>Thanks again.  Please propose text and we can review 
> whether we get 
> > >>any better guarantees and functionality.
> > >>
> > >>regards,
> > >>Lakshminath
> > >>
> > >>>>The keyword being "attempts" and the intention being to 
> cover the 
> > >>>>case of no responses from the peer and legitimate failures.  
> > >>>>Consider that the CREATE_CHILD_SA looks like this:  
> HDR, SK {IDi, 
> > >>>>[CERT,] [CERTREQ,] [IDr,]
> > >>>>                 AUTH, SAi2, TSi, TSr}
> > >>>>
> > >>>>Are you saying that sending a legitimate HDR followed by some 
> > >>>>garbage will close an IKE SA?  It is definitely not the case.
> > >>>layers and AAA protocols to support "proactive rekeying" 
> in which 
> > >>>two SAs can exist in a short amount of time to allow smooth 
> > >>>migration from one SA to another during rekey.  IKEv2 has this 
> > >>>property which is seems nice.
> > >>>
> > >>>>On rMSK transport, our intern found that the guidance available 
> > >>>>now is sufficient (and that implementation was done in 
> open source 
> > >>>implemented?  I am asking because I did not see any consensus on 
> > >>>key transport security protocol yet.
> > >>>
> > >>>Regards,
> > >>>Yoshihiro Ohba
> > >>>
> > >>>
> > >>>>>>>[1] Regarding Issue 15, I saw text (quoted below) on 
> > >>>>>>>re-authentication DoS in Security Considerations, which is a 
> > >>>>>>>good thing.  However, I am wondering if the suggested 
> > >>>>>>>mitigation method is creating another problem.
> > >>>>>>>
> > >>>>>>>"
> > >>>>>>>In addition, a denial of service attack may be 
> possible using 
> > >>>>>>>the EAP Iniaite/Re-auth message.  The attacker sends a bogus 
> > >>>>>>>EAP Initiate Re- auth message, which may be carried by the 
> > >>>>>>>authenticator in a RADIUS- Access-Challenge to the 
> server; in 
> > >>>>>>>response to that the server may send a RADIUS- 
> Access-Reject.  
> > >>>>>>>Note that such attacks may be plausible with the EAP-Start 
> > >>>>>>>capability of 802.11 and other similar facilities in 
> other link 
> > >>>>>>>layers and where the peer can initiate EAP 
> authentication; an 
> > >>>>>>>attacker may use such message to start an EAP method 
> run, which 
> > >>>>>>>fails and may result in the server sending a 
> > >>>>>>>RADIUS-Access-Reject message.  To mitigate the 
> impact of such 
> > >>>>>>>DoS attacks, the authenticator must not tear down any link 
> > >>>>>>>layer connections as long as there is at least one 
> active MSK 
> > >>>>>>>and an active RADIUS session (e.g., lifetime has not 
> expired).  
> > >>>>>>>It appears that some implementations at the time of 
> this writing already employ such mitigation techniques.
> > >>>>>>>"
> > >>>>>>>
> > >>>>>>>If the authenticator does not tear down link-layer 
> connections 
> > >>>>>>>when re-authentication fails when there is at least 
> one active 
> > >>>>>>>MSK and an active RADIUS session, what is the purpose of 
> > >>>>>>>performing re-authentication?
> > >>>>>>In the above case, there was no re-authentication.  
> There was a 
> > >>>>>>bogus message sent by an adversary which the RADIUS server 
> > >>>>>>recognizes as bogus.
> > >>>>>Not necessarily.  In general, a re-authentication 
> failure could 
> > >>>>>happen without a DoS attack by a legitimate peer which used 
> > >>>>>invalid credentials due to, e.g., password mistyping.  It is 
> > >>>>>difficult to tell whether a particular 
> re-authentication is under 
> > >>>>>a DoS attack or a just an errneous case.
> > >>>>>
> > >>>>>>>In my understanding, re-authentication is performed 
> to modify 
> > >>>>>>>authorization-related attributes including authorization 
> > >>>>>>>lifetime.  In the current practice as far as I know, if 
> > >>>>>>>re-authentication fails, authorization state including 
> > >>>>>>>link-layer sessions is deleted, and there is nothing 
> wrong with it.
> > >>>>>>>
> > >>>>>>>However, the text seems to suggest changing the current 
> > >>>>>>>practice *just to deal with re-authentication DoS attack for 
> > >>>>>>>ERX bootstrapping*.
> > >>>>>mitigation technique to the attack seems just wrong.  
> I can show 
> > >>>>>an analogy here.  In IKEv2, when rekeying an IKE_SA fails, the 
> > >>>>>IKE_SA and any associated CHILD_SAs must be closed.  If the 
> > >>>>>IKE_SA associated CHILD_SAs are not closed when the rekeying 
> > >>>>>fails, then there will be an uncertain time period in 
> which the 
> > >>>>>authenticity of the initiator is lost but the SAs still exist, 
> > >>>>>which does not show a good security property.
> > >>>>>
> > >>>>>>>Note that re-authentication DoS attack in general can be 
> > >>>>>>>mitigated by simply not allowing immediate 
> re-authentication at the link layer.
> > >>>>>>>Since requiring this specific mitigation can significantly 
> > >>>>>>>affect the current AAA deployment, I don't think it's 
> > >>>>>>>reasonable to require or recommend this specific 
> mitigation technique.
> > >>>>>I don't agree with that the technique is recommended as I 
> > >>>>>explained above.
> > >>>>>
> > >>>>>>>[2] Regarding Issue 22, erx draft should contain a normative 
> > >>>>>>>reference to draft-ietf-hokey-key-mgm-00.txt with indicating 
> > >>>>>>>that the key distribution mechanism is specified in 
> the key-mgm 
> > >>>>>>>draft.  Otherwise, what is the purpose of the key-mgm draft?
> > >>>>>>informative reference can be associated with a nod to 
> the other 
> > >>>>>>work and the relative positioning.
> > >>>>>My comment is based on the fact that ERX has a dependency on a 
> > >>>>>key distribution mechanism for its deployment.  It is not 
> > >>>>>possible to implement ERX without implementing a key 
> distribution 
> > >>>>>mechanism.  The key distribution mechanism is specified in 
> > >>>>>key-mgm draft.  So key-mgm draft has to be a normative 
> reference.  
> > >>>>>There is text (quoted below) about key distribution, 
> but I think 
> > >>>>>this text is too ambiguous to implement (and this is 
> what Issue 
> > >>>>>22 is talking about, right?)
> > >>>>>
> > >>>>>>>>Thanks for putting together the revision.  I've updated the 
> > >>>>>>>>tracker with the changes indicated below.  The document 
> > >>>>>>>>authors felt that the following issues were non-issues:
> > >>>>>>>>
> > >>>>>>>>There hasn't been any subsequent conversation on 
> the list.  If 
> > >>>>>>>>you disagree, please post your comments to the list by 
> > >>>>>>>>September 20, otherwise we'll close the issues and 
> proceed to WGLC.
> > >>>>>>>>
> > >>>>>>>>--
> > >>>>>>>>>Do you want us to fix the rIK length issue now or 
> wait and do 
> > >>>>>>>>>it as part of the WGLC?  Are there any pending 
> issues before 
> > >>>>>>>>>issuing an LC on this document?
> > >>>>>>>>>
> > >>>>>>>>>thanks,
> > >>>>>>>>>Lakshminath
> > >>>>>>>>>
> >>>>>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-hokey
> -erx-04.txt.
> > >>>>>>>>>>The
> > >>>>>>>>>>authors believe that this revision captures all 
> the issues 
> > >>>>>>>>>>that need to be addressed based on the issues tracker 
> > >>>>>>>>>>(status detailed below) and that the document is 
> ready for 
> > >>>>>>>>>>WGLC.  Assuming the chairs believe that the 
> issues have been 
> > >>>>>>>>>>resolved satisfactorily, we request them to issue a last 
> > >>>>>>>>>>call on the document.
> > >>>>>>>>>>Thanks,
> > >>>>>>>>>>Vidya
> > >>>>>>>>>>
> > >>>>>>>>>>Resolved - added EAP Initiate Re-auth-Start message for 
> > >>>>>>>>>>authenticator initiation
> > >>>>>>>>>>
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Resolved - changed title to "EAP Extensions for EAP 
> > >>>>>>>>>>Re-authentication Protocol (ERP)" to include ERP in the 
> > >>>>>>>>>>title
> > >>>>>>>>>>
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>There was no consensus on changing the terms. Hence, no 
> > >>>>>>>>>>changes have been done in this revision.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Issue 15: ERX: bootstrapping possibly broken No technical 
> > >>>>>>>>>>issues with ERP bootstrapping were noted.  We are not 
> > >>>>>>>>>>suggesting any changes to the EAP behavior or use 
> of the MSK 
> > >>>>>>>>>>produced by EAP - hence, any restrictions/changes 
> to the use 
> > >>>>>>>>>>of the MSK is inappropriate for this document.  Hence, no 
> > >>>>>>>>>>changes are needed here.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>The use of rIK for the ERP exchange itself is 
> appropriate, 
> > >>>>>>>>>>since it uses an integrity key that is produced for the 
> > >>>>>>>>>>context of re-authentication.
> > >>>>>>>>>>If the re-authentication functions were performed by an 
> > >>>>>>>>>>entity other than the EAP server (EMSK holder), this 
> > >>>>>>>>>>produces no dependencies on any key outside the 
> > >>>>>>>>>>re-authentication key hierarchy.  Hence, no changes are 
> > >>>>>>>>>>needed here.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Cryptographically, the necessary separation 
> across rMSKs is 
> > >>>>>>>>>>provided by the sequence number.  The EAP methods 
> do not use 
> > >>>>>>>>>>any authenticator IDs in the MSK generation as well.  So, 
> > >>>>>>>>>>there is no need to include identities in the rMSK 
> > >>>>>>>>>>generation either.  Channel binding support is 
> provided in 
> > >>>>>>>>>>ERP and that can be used to assert identities when needed.
> > >>>>>>>>>>The lower layer may choose to include the appropriate 
> > >>>>>>>>>>identities in the TSK generation (as some lower layers 
> > >>>>>>>>>>already do).
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Issue 22: ERX: key transport and refs to key mgt doc Open 
> > >>>>>>>>>>issue; not sure what the reference would be needed for.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Subsequent consensus is not to derive DSUSRKs 
> from USRKs.  
> > >>>>>>>>>>Hence, this issue is no longer valid.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>
> > >>>>>>>>>>Subsequent to the discussion at IETF69, this no 
> longer seems 
> > >>>>>>>>>>to be an issue.
> > >>>>>>>>>>------------------------
> > >>>>>>>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 25 Sep 2007 15:49:09 -0400

Vidya,

> why the AAA server would need to know anything about the link-layer SA.

I don't mean it.  The AAA server just needs to know the existence of
two overlapping authorizations associated with two different
lifetimes, each of the authorizations would be associated with each
one of the two link-layer SAs, by the NAS, not necessarily by the AAA
server.

> Reject.  It should only delete state corresponding to that EAP session. 

But the legacy AAA server will entirely delete its authorization state
after sending the Reject, which should not happen here, right?  

> running a full EAP if ERP happens to fail too often. 

In general, EAP state and network access authorization state are
different, and I am not talking about the EAP state.  The legacy AAA
server does not keep the network access authorization state for the
peer to use a particular NAS once it returns the Reject to the NAS,
while an EAP state (e.g., EAP-TLS session state for session
resumption) may stay on the AAA server depending on implementations.

> imply that RFC4306 is broken... 

I don't think RFC4306 is broken.  It actually works if EAP server is
co-located with IKEv2 responder.  I would say that the entire system
that uses RFC4306 combined with EAP *and* legacy AAA protocols is
probably not sufficient to support proactive rekeying if we consider
the network access authorization aspect I explained above.

> In any event, let's focus on the

Why not relevant?  I believe that IKEv2-analogy is an important and
essential thing to think about to have a better key replacement (or
proactive rekeying) scheme.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Sep 2007 13:03:11 +0700

A couple of problems with both the things: Access-Challenge messages only
originate from the RADIUS server, so it seems pretty much impossible for
anything to be carried in such from the Authenticator.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 9:15 PM
To: Lakshminath Dondeti
Cc: [email-masked]
Subject: Re: [HOKEY] draft-ietf-hokey-erx-04 - Revision and Fixes to Issues
from Tracker

Here is my suggestion.

"

to:

"

Regards,
Yoshihiro Ohba

> >>>>>[1] Regarding Issue 15, I saw text (quoted below) on
re-authentication
> >>>>> In addition, a denial of service attack may be possible using the
EAP
> >>>>>[2] Regarding Issue 22, erx draft should contain a normative
reference
> >>>>What do we need to refer to in that document?  I couldn't find
anything 
> >>>>>>with the changes indicated below.  The document authors felt that
the 

> >>>>>>>>authenticator
> >>>>>>>>Re-authentication
> >>>>>>>>The use of rIK for the ERP exchange itself is appropriate, since
it 
> >>>>>>>>uses
> >>>>>>>>than the EAP server (EMSK holder), this produces no dependencies
on 
> >>>>>>>>any
> >>>>>>>>key outside the re-authentication key hierarchy.  Hence, no
changes 
> >>>>>>>>are
> >>>>>>>>the sequence number.  The EAP methods do not use any authenticator

> >>>>>>>>IDs
> >>>>>>>>identities in the rMSK generation either.  Channel binding support

> >>>>>>>>is
> >>>>>>>>The lower layer may choose to include the appropriate identities
in 
> >>>>>>>>the
> >>>>>>>>Subsequent to the discussion at IETF69, this no longer seems to be

> >>>>>>>>an

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 26 Sep 2007 23:14:56 -0700

Glen,

Yeah, you are correct.  It should be Access-Request from the 
Authenticator to the Server.

What do you think is the best way forward from here?  Thanks.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 27 Sep 2007 13:36:46 -0700

Yoshi,

I agree that RADIUS Access-Reject processing at the ER server and the 
NAS does need to change in that, because EAP Finish Reauth (indicating a 
failure) may be due to a bogus ERP message sent by an adversary.  The 
change is that existing peer authorization state must not be deleted 
upon ERP failure, given that possibility of an attack.  Existing 
authorizations will be deleted when they expire.

We can indicate that and close this issue.  Thanks.

regards,
Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Fri, 28 Sep 2007 08:48:30 -0400

I've closed the following issues due to a lack of consensus for making 
any changes:
  - 16: "terminology issues"
  - 19: "location of integrity key"
  - 21: "rMSK derivation id/seq"
  - 23: "root key -- USRK or DSUSRK?"

Issues 15 and 22 will remain open until the next ERP rev is submitted 
that addresses them.

After that, we can go to WGLC on ERP.