Re: [HOKEY] AD review of draft-ietf-hokey-rfc5296bis

[Glen Zorn <[e-mail]>]

On 2/9/2012 1:43 AM, Stephen Farrell wrote:
> 
> Hi all,
> 
> My review on this is below. All of those comments
> can be handled along with any other IETF LC comments
> received and none is a big deal. However there is one
> thing to sort out before we go ahead.
> 
> There is an IPR declaration for 5296 but none for this
> document, which is very similar.
> 
> We should get that sorted out before IETF LC one way or
> another. Best is to get a new declaration from the folks
> who declared about 5296.
> 
> It may be that an additional short WGLC just to check
> this would be useful for the record once the chairs
> find out if a new IPR declaration will be forthcoming
> in the near future. (I've asked Tina as shepherd to
> handle this.)
> 
> Thanks,
> S.
> 
> - Some references need updating, check ID-nits.

OK.

> 
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-hokey-rfc5296bis-06.txt
> 
> 
> The next three comments are about stuff that didn't really
> change since 5296, so consider them suggestions (i.e.
> I won't insist on any changes being made).
> 
> - 3.2, 1st para: "The peer uses the domain name..." is that
> the home or visited domain name?  Same thing in the 3rd last
> para of 3.2 and various other places. Which domain name
> is used when could be clearer throughout I think.

Just looking at 3.2, it really seems that the domain name in question is
quite clear from the context(and the fact that the name is used in the
computation of a DSRK, which only used in a roaming situation).

> 
> - p18, last bullet is not quite clear on when a message is
> considered fresh. I think it means that any sequence number
> greater than the last one used is ok, and any less is
> considered a replay but I'm not 100% sure from this text, but
> 5.4 does seem to say that. Be good to be as clear here too.

Sorry, but again I'm just not getting it :(.  The start of the bullet in
question reads:

      Upon receipt of an EAP-Initiate/Re-auth message, the home ER
      server verifies whether the message is fresh or is a replay by
      evaluating whether the received sequence number is equal to or
      greater than the expected sequence number for that rIK.

Whats not clear?

> 
> - 8, "confidentiality of identity" - does the use of some of
> the channel bindings not expose identity? If so, noting that
> here would be good.

Excellent point!  How's this?

      Confidentiality of identity

         Deployments where privacy is a concern may find the use of
         rIKname-NAI to route ERP messages serves their privacy
         requirements.  Note that it is plausible to associate multiple
         runs of ERP messages since the rIKname is not changed as part
         of the ERP protocol.  There was no consensus for that
         requirement at the time of development of this specification.
         If the rIKname is not used and the Peer-ID is used instead, the
         ERP exchange will reveal the Peer-ID over the wire.  The use of
         channel bindings may compromise identity confidentiality, as
         well, for example, if the Calling-Station-ID AVP is used and
         contains a value that can be linked to a user (e.g., a
         telephone number).

> 
> nits:
> 
> - DSRK is not expanded before 1st use in section 2.

True; neither is 'EMSK'.  That is because the acronyms are defined in
RFC 5295 and RFC 3748, respectively, which are normative references
cited before the first usage of either term.

> 
> - DS-rIK and DS-rRK are used with out expansion or
> explanation. (last para before 3.1)

OK.

> 
> - 3.2, 1st para: s/out of home domain/out of the home domain/

OK.

> 
> - 5.1, 1st para: s/If ER capable.../If an ER capable.../

OK, probably needs a hyphen, too.

> 
> - 3.2 s/Figure 5shows/Figure 5 shows/

OK.

> 
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey