Subject: [HOKEY] Comments on draft-ietf-hokey-reauth-ps-05.txt (Part 1)

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Nov 2007 20:11:11 -0800

Abstract

Sentence 2

s/EAP/Extensible Authentication Protocol/

Sentence 3 

s/This often cause/This often causes/

Sentence 4

Change 

HOKEY plans to address these HOKEY plans to address these problems by
implementing a generic mechanism to reuse derived EAP keying material for
handover.

To

The HOKEY Working Group plans to address these problems by designing a
generic mechanism to reuse derived EAP keying material for handover.

Section 1

Please move this section below the "IANA Considerations" section.  Don't use
the word "authors" to refer to these people; if they are really authors then
they deserve to be listed with you in the first page header.  If you want to
list contact information for the contributors, please use the same format as
that used for the "Author's Address" section.

Section 2

Paragraph 1

Change 

the master session key (MSK) and the extended MSK (EMSK).

To

the Master Session Key (MSK) and the Extended Master Session Key (EMSK).

Paragraph 3

Change

transient session keys (TSK) used per-packet access encryption and
enforcement.

To

Transient Session Keys (TSKs) used for per-packet encryption and
authentication.

Paragraph 4

This is correct as far as it goes, but in conjunction with the 2 preceding
paragraphs gives the impression that there are actually 3 parties involved
in the EAP conversation, the "peer", the "authenticator" and the "server".
This is incorrect; in fact, the delineation between the "authenticator" and
the "server" is just a special case of the division of the single logical
authenticator across multiple physical devices.  I suggest reworking
paragraphs 2-4 to better reflect this.

Paragraph 5

Change

The current models of EAP authentication and keying are unfortunately not
efficient in case of mobile and wireless networks.  

To

The current models of EAP authentication and keying are unfortunately not
efficient in cases where the peer is a mobile device.

Not sure what "re-affirm its access through the current authenticator"
means.

Change

A full EAP method execution may involves several round trips between the EAP
peer and the server.

To

A full EAP method execution may involve several round trips between the EAP
peer and the server.

Paragraph 7

Change

This document provides a detailed description of EAP efficient
re-authentication protocol requirements.

To

This document provides a detailed description of efficient EAP-based
re-authentication protocol requirements.

Section 4

Paragraph 3

I don't know what a "re-authentication domain" is & the term doesn't seem to
be defined anywhere in this document; given that, I really have no idea what
"handover keying" might be.

 

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

---

From: Charles Clancy <[email-masked]>
Date: Tue, 06 Nov 2007 13:14:14 -0500

Glen,

I've posted -06 addressing your comments.

http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-06.txt

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

Glen Zorn wrote:
> *_Abstract_*
> _Sentence 2_
> _Sentence 3_
> _Sentence 4_
> implementing a generic mechanism to reuse derived EAP keying material 
> for handover.
> 
> To
> 
> *_Section 1_*
> Please move this section below the "IANA Considerations" section.  Don't 
> use the word "authors" to refer to these people; if they are really 
> authors then they deserve to be listed with you in the first page 
> header.  If you want to list contact information for the contributors, 
> please use the same format as that used for the "Author's Address" section.
> 
>  
> 
> *_Section 2_*
> 
> _Paragraph 1_
> 
> Change
> 
> _Paragraph 3_
> _Paragraph 4_
> This is correct as far as it goes, but in conjunction with the 2 
> preceding paragraphs gives the impression that there are actually 3 
> parties involved in the EAP conversation, the "peer", the 
> "authenticator" and the "server".  This is incorrect; in fact, the 
> delineation between the "authenticator" and the "server" is just a 
> special case of the division of the single logical authenticator across 
> multiple physical devices.  I suggest reworking paragraphs 2-4 to better 
> reflect this.
> 
>  
> 
> _Paragraph 5_
> 
> Change
> 
> The current models of EAP authentication and keying are unfortunately 
> not efficient in case of mobile and wireless networks. 
> 
> To
> 
> The current models of EAP authentication and keying are unfortunately 
> not efficient in cases where the peer is a mobile device.__
> 
> _ _
> 
> A full EAP method execution may involves several round trips between the 
> EAP peer and the server.
> 
> To
> 
> A full EAP method execution may involve several round trips between the 
> EAP peer and the server.
> 
>  
> 
> _Paragraph 7_
> 
> Change
> 
> *_Section 4_*
> _Paragraph 3_
> I don't know what a "re-authentication domain" is & the term doesn't 
> seem to be defined anywhere in this document; given that, I really have 
> no idea what "handover keying" might be.
> 
>  
> 
>  
> 
>  
> 
>  
>