Subject: RE: [HOKEY] WGLC comments for erx-05

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

Hi Pasi,
Thanks much for your comments again.  I've removed all comments that
have been addressed from this list.  Please find responses to
clarification questions or comments not addressed below.  
 
> S4.1.1, "S = rRK Label + "\0" + NULL + length". Is this 
> intentionally two nulls?
>

Unfortunately, yes.  All key derivations follow the EMSK hierarchy
document and that allows for inclusion of Optional Data as part of key
derivation after the null termination.  For the rRK, there is no
optional data and hence, that field is set to NULL.  
 
> S5.3.2, Why does the EAP Finish Re-auth packet contain the 
> peer's NAI? Or should it contain Server-ID instead?
> 

Removed the peer-ID from the EAP-Finish/Re-auth message.  It is
redundant and not needed anyway.  

> S5: What is the relationship between the rIKname sent in the 
> Initiate message, and the one received in the Finish message? 
>  (Are they supposed to be the same? Is the peer expected to 
> use the latter one when sending the next Initiate message? Or 
> something else?)
> 

The two rIKname parameters are the same - it is just a key name and
hence, simply serves to lookup the right key.  The peer can
alternatively match the response to the request and lookup the correct
key (when it has multiple rIKs with different servers), but, I think
having it explicitly included is better. 

> S6, The list of requirements here does not match exactly the 
> list in RFC 4962; the differences should be at least explained.
> 

The differences were an unintentional miss; it is fixed now. 

> S6, Peer-ID privacy: the security considerations section 
> should note that ERX exposes the Peer-ID over the wire.
> 

Added wording to clarify that when the peer-ID is used in the exchange,
it is exposed.  However, it is only optional to include the peer-ID; the
rIKname-NAI is sufficient for AAA routing of the message and hence,
there is no real need for the peer-ID. 

> General: The document should explain what is the relationship 
> (if any) between the ERX peer-ID and the Peer-ID exported by 
> the EAP method (and likewise for Server-ID).
> 

They are the same. Clarified it in the document. 

> General: The document does not seem to specify how DSRKs are 
> derived; this looks like a missing normative reference (+ 

Added the appropriate reference to the EMSK hierarchy draft. 

> missing details on what particular data item from ERX 
> messages is used and how).
> 

I assume you are talking about indicating the inputs used from the
messages for DSRK derivation.  The peer may obtain the domain id
required for DSRK computation from an ERP bootstrapping exchange and
that is defined in section 5.1.1.  The home ER server gets the relevant
information from the AAA exchange and that is defined by the appropriate
RADIUS and Diameter drafts (references are included in the revised draft
in appropriate places). 

> General: What's the reason for specifying three different 
> variants of HMAC-SHA256 with different authentication tag 
> lengths? (Just saving a couple of bytes in packet size, or 
> something else?)

Well, yes :) We have specified a mandatory to implement one based on
Charles' and Katrin's comments. 

> General: The document uses terms such as "EAP Session-ID" 
> without citing a document that defines them (i.e., eap-keying draft).
> 

It is an indirect reference, since this document only uses the EAP
Session-ID in key name derivation as defined by the EMSK hierarchy
document.  The reference to EAP keying is from the latter document that
actually defines the usage in key name derivations. 

Thanks,
Vidya

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