Subject: [HOKEY] WGLC comments on ER

From: "Katrin Höper" <[email-masked]>
Date: Thu, 1 Nov 2007 15:31:16 -0400

Hi all,

Some comments about <draft-ietf-hokey-erx-05>.

My comments focus on the security of the proposed protocol(s). Even
though I could not find any direct attack on the protocol, there are a
few design choices that may lead to security vulnerabilities. Some
editorial comments are listed at the end. [I am new to the list, so
please excuse me if I raise questions about previously discussed
topics.]

Best regards,
Katrin Hoeper

DESIGN QUESTIONS/TECHNICAL COMMENTS…

… about the re-auth protocol

In the proposed protocol the received sequence number SEQ (as part of
the EAP Initiate Re-auth packet) is identical to the number included
in the response (EAP Finish Re-Auth Packet)— why? It seems desirable
to use a different sequence number, let's say SEQ_p and SEQ_s, for
each authentication direction. Also, wouldn't it be more desirable to
manipulate the received sequence numbers in a specified way ( e.g.
increment, inverse, etc.) before including it in the response message?
Such manipulations would further ensure that Init and Finish packets
do not look too similar and thus provide additional security for
replay attack prevention. These protocol modifications wouldn't
increase the communication complexity.

Is there any technical reason why the length of the sequence number is
restricted to 16 bits? If not, it may be desirable to select a larger
size, let's say 32 bits.

The documents should specify what happens if one or both endpoints
(peer and/or server) loose the current state (sequence number). This
case is currently not covered in the failure handling. The execution
of a full EAP authentication seems the obvious answer; however this
must be spelled out to allow a proper protocol implementation.

In the protocol the peer selects the integrity protection algorithm to
avoid costly ciphersuite negotiations. However, without any mandatory
ciphersuite(s) it may take several rounds until the server agrees on
the selected algorithm and in some cases such an agreement might be
completely infeasible. For this reason, it seems desirable to specify
at least one ciphersuite (integrity protection algorithm) that is
mandatory to implement. The cryptosuites specified in Sect 5.3.1 are
in compliance with FIPS-198 and thus seem to be a suitable choice.
However, if it is assumed by the authors that peer and server have
agreed on acceptable integrity protection algorithms out-of-band prior
protocol execution, this assumption must be spelled out in the
document.

… about the key derivation

None of the derived keys (rRK, rIK, rMSK) contain identifiers of all
entities that are able to derive the keys. Including identifiers binds
keys to their context and would be in compliance with NIST SP-56A.

rMSK only contains a "fresh" value from the peer, namely SEQ. It may
be desirable to include fresh inputs from both peer and server ( e.g.
SEQ_p and SEQ_s when using two sequence numbers or SEQ and a nonce N_s
that is selected by the server and included in the finish packet).

FALSE SECURITY CLAIMS IN SECTION 6
(*note: enumeration of security claims would be helpful for references!)

It is not true that both peer and server contribute nonces to the rMSK
derivations. Nonces are not used at all in the protocol and only the
peer contributes a sequence number.

Keys are not bound to their context because they do not contain
identifiers. As a consequence, rMSK is only bound to peer and server
IDs if the EMSK already contains these identifiers. However this is
EAP method dependant and generally not true.

EDITORIAL COMMENTS

Section 1:
Already provides comparison for method-independent EAP vs. EAP
method-dependent re-authentication, but what about EAP vs. wireless
technology-dependent re-authentication? E.g. IEEE 802.11 and .16
provide mechanisms for re-authentication (called fast transitions and
fast re-association, resp.). Should proposed re-authentication only be
used for inter-technology handovers?
Comparison to solutions in [7] and [8] missing, e.g. why aren't those
solutions sufficient?

Section 4:
Repeat the following definitions for document to be self-contained:
prf [3]
prf+ [3]
EAP Session-ID [EAP Key Management Framework]
DSRK name [3]

Section 5.1:
The section should be restructured for better readability and a
clearer distinction of the different types of bootstrapping, e.g.
Section 5.1.1 Implicit Bootstrapping, Section 5.1.2 Explicit
Bootstrapping, and Section 5.1.3 Explicit Bootstrapping with a Local
ER Server.

Section 5.3.1, page 21, TV or TVLs:
First sentence repeated twice.

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 23:25:04 -0800

Hi Katrin,
Thanks for the comments.  Please see some notes inline for those not addressed in the draft revision.  

> 
> DESIGN QUESTIONS/TECHNICAL COMMENTS...
> 
> ... about the re-auth protocol
> 
> In the proposed protocol the received sequence number SEQ (as 
> part of the EAP Initiate Re-auth packet) is identical to the 
> number included in the response (EAP Finish Re-Auth Packet)- 
> why? It seems desirable to use a different sequence number, 
> let's say SEQ_p and SEQ_s, for each authentication direction. 
> Also, wouldn't it be more desirable to manipulate the 
> received sequence numbers in a specified way ( e.g.
> Such manipulations would further ensure that Init and Finish 
> packets do not look too similar and thus provide additional 
> security for replay attack prevention. These protocol 
> modifications wouldn't increase the communication complexity.
> 

There is no good reason to use different sequence numbers and that actually introduces the possibility of falling out of sync.  This mechanism of using the same sequence number is followed in several protocols (e.g., IKEv2) and it is not an issue. 

> Is there any technical reason why the length of the sequence 
> number is restricted to 16 bits? If not, it may be desirable 
> to select a larger size, let's say 32 bits.
> 

The rIK must be rekeyed when the sequence number rolls over.  2^16 ERP exchanges can be done before that happens. That's a lot of exchanges for the key to survive that long anyway.  It is likely that the peer will power off or the lifetime will expire before 2^16 re-authentication exchanges occur.  So, a larger sequence number doesn't seem useful to me. 

> The documents should specify what happens if one or both 
> endpoints (peer and/or server) loose the current state 
> (sequence number). This case is currently not covered in the 
> failure handling. The execution of a full EAP authentication 
> seems the obvious answer; however this must be spelled out to 
> allow a proper protocol implementation.
> 

I'm not sure I understand.  The peer increments its sequence number as soon as it sends out the EAP-Initiate message.  The server increments its sequence number as soon as it receives that message.  The peer should never use the same sequence number for a subsequent ERP exchange.  The server accepts a given sequence number only as long as it is greater than what it expects.  So, there doesn't seem to be a problem here.  Please let us know if you think section 5.4 missed something and if there is a case where the two entities may be out of sync.  Please note that if one of the entities reboots or crashes, all state is lost and the rIK is not available any more.  As long as the two entities are up and functional, everything should work fine. 

> In the protocol the peer selects the integrity protection 
> algorithm to avoid costly ciphersuite negotiations. However, 
> without any mandatory
> ciphersuite(s) it may take several rounds until the server 
> agrees on the selected algorithm and in some cases such an 
> agreement might be completely infeasible. For this reason, it 
> seems desirable to specify at least one ciphersuite 
> (integrity protection algorithm) that is mandatory to 
> implement. The cryptosuites specified in Sect 5.3.1 are in 
> compliance with FIPS-198 and thus seem to be a suitable choice.
> However, if it is assumed by the authors that peer and server 
> have agreed on acceptable integrity protection algorithms 
> out-of-band prior protocol execution, this assumption must be 
> spelled out in the document.
> 

Added mandatory to implement cryptosuite. 

> ... about the key derivation
> 
> None of the derived keys (rRK, rIK, rMSK) contain identifiers 
> of all entities that are able to derive the keys. Including 
> identifiers binds keys to their context and would be in 
> compliance with NIST SP-56A.
> 

None of the EAP keys (MSK or EMSK) include identities in key derivations and we are only producing MSK-equivalent keys in the rMSK.  So, there is no need to include any identities here.  This was discussed in the WG and there was no consensus to adding identities in the derivation.  

> rMSK only contains a "fresh" value from the peer, namely SEQ. 
> It may be desirable to include fresh inputs from both peer 
> and server ( e.g.
> SEQ_p and SEQ_s when using two sequence numbers or SEQ and a 
> nonce N_s that is selected by the server and included in the 
> finish packet).
> 

The initial versions of this protocol did include server side nonces as well.  However, after input from the crypto community, it was removed.  Publicly exchanged nonces do not add any entropy to the keys.  The replay protection needs to be provdided using sequence numbers for a 2-msg exchange anyway and hence, there is no good reason to include additional nonces. 

> It is not true that both peer and server contribute nonces to 
> the rMSK derivations. Nonces are not used at all in the 
> protocol and only the peer contributes a sequence number.
> 

Thanks for catching this.  This was a result of the old versions where there was a server side nonce.  The text has been corrected. 

> Keys are not bound to their context because they do not 
> contain identifiers. As a consequence, rMSK is only bound to 
> peer and server IDs if the EMSK already contains these 
> identifiers. However this is EAP method dependant and 
> generally not true.
> 

Again, please see above notes on identity binding.  Also, TSKs typically include lower layer identities in key generation and hence, the actual session keys have the property you are looking for.  

> 
> EDITORIAL COMMENTS
> 
> Section 1:
> Already provides comparison for method-independent EAP vs. 
> EAP method-dependent re-authentication, but what about EAP 
> vs. wireless technology-dependent re-authentication? E.g. 
> IEEE 802.11 and .16 provide mechanisms for re-authentication 
> (called fast transitions and fast re-association, resp.). 
> Should proposed re-authentication only be used for 
> inter-technology handovers?
> Comparison to solutions in [7] and [8] missing, e.g. why 
> aren't those solutions sufficient?
> 

The problem statement draft describes the need for this solution.  The references to other solutions are only cited here for completeness and the goal is not to provide any comparisons in this document itself. 

> EAP Session-ID [EAP Key Management Framework] DSRK name [3]
> 

Repetition of definitions is not useful.  If the references are updated, this document will also need to be udpated and that's not good.  

> Section 5.1:
> The section should be restructured for better readability and 
> a clearer distinction of the different types of bootstrapping, e.g.
> Bootstrapping, and Section 5.1.3 Explicit Bootstrapping with 
> a Local ER Server.
> 

Implicit bootstrapping requires no ERP support and is hence, described in 2 lines - so, a separate section on it doesn't seem useful.  The explicit bootstrapping with a local ER server is already explained in a separate section. 

> First sentence repeated twice.

The two sentences are different - the first one refers to a TV payload and the second one refers to a TLV payload.  The sentences just start off the same way :) 

Thanks!
Vidya

---

From: "Katrin Höper" <[email-masked]>
Date: Thu, 8 Nov 2007 11:55:55 -0500

Hey Vidya,

thank you for your clarifying comments.
I have only two follow up comments, see inline (first one just a
comment, latter one asking for a change in the current draft -06).

Thank you,
Katrin

> There is no good reason to use different sequence numbers and that actually introduces the possibility of falling out of sync.  This mechanism of using the same sequence number is followed in sever…
OK accepted. But I am not sure if your reference to IKEv2 is that
accurate, because IKEv2 uses sequence numbers and nonces (one in each
direction).

> Again, please see above notes on identity binding.  Also, TSKs typically include lower layer identities in key generation and hence, the actual session keys have the property you are looking for.

OK so there are no identifiers in the key derivation.
But then the statement in Section 6, page 3, last sentence in
paragraph "Bind key to its context",
\quote Also, the rMSK is bound to the peer and server IDs. \quote
is wrong and should be corrected. As mentioned in my original
comments, rMSK is only bound to peer and server IDs if the EMSK
already contains these identifiers. However this is EAP method
dependant and generally not true. Your explanations about TSKs doesn't
apply to the rMSK statement.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 8 Nov 2007 11:31:07 -0800

Hi Katrin,

> > Again, please see above notes on identity binding.  Also, 
> TSKs typically include lower layer identities in key 
> generation and hence, the actual session keys have the 
> property you are looking for.
> 
> paragraph "Bind key to its context", \quote Also, the rMSK is 
> bound to the peer and server IDs. \quote is wrong and should 
> be corrected. As mentioned in my original comments, rMSK is 
> only bound to peer and server IDs if the EMSK already 
> contains these identifiers. However this is EAP method 
> dependant and generally not true. Your explanations about 
> TSKs doesn't apply to the rMSK statement.
> 

Thanks for catching this! I just went back to the very first version, draft-vidya-eap-er-00, and found that we did start off by having the peer-id in the rMSK derivation and that's when that statement was written :)  Subsequently, while the draft evolved based on discussions to not have ids in the rMSK (and just have MSK equivalence), the text in the security considerations seems to not have evolved with it.  Apologies for the confusion - we will get the text clarified in the security considerations in the next revision. 

Thanks!
Vidya

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Nov 2007 16:45:24 -0800

Following up on this, we'll update the draft before the draft deadline 
as per Vidya's note below. Any other open issues?

Charles, Glen,

what are the next steps on this after the next revision?

thanks,
Lakshminath

On 11/8/2007 11:31 AM, Narayanan, Vidya wrote:
>> TSKs typically include lower layer identities in key generation and
>> hence, the actual session keys have the property you are looking
>> for.
>> 
>> OK so there are no identifiers in the key derivation. But then the
>> statement in Section 6, page 3, last sentence in paragraph "Bind
>> key to its context", \quote Also, the rMSK is bound to the peer and
>> server IDs. \quote is wrong and should be corrected. As mentioned
>> in my original comments, rMSK is only bound to peer and server IDs
>> if the EMSK already contains these identifiers. However this is EAP
>> method dependant and generally not true. Your explanations about 
> Thanks for catching this! I just went back to the very first version,
> draft-vidya-eap-er-00, and found that we did start off by having the
> peer-id in the rMSK derivation and that's when that statement was
> written :)  Subsequently, while the draft evolved based on
> discussions to not have ids in the rMSK (and just have MSK
> equivalence), the text in the security considerations seems to not
> have evolved with it.  Apologies for the confusion - we will get the
> text clarified in the security considerations in the next revision.
> 
> Thanks! Vidya
> 
> _______________________________________________ HOKEY mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/hokey
>

---

From: Charles Clancy <[email-masked]>
Date: Mon, 12 Nov 2007 23:34:08 -0500

I'm not aware of any open issues.  I'll get started on a proto writeup.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Lakshminath Dondeti wrote:
>>> method dependant and generally not true. Your explanations about TSKs 
>>> doesn't apply to the rMSK statement.
>>>
>>