[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Glen,

On 02/09/2012 09:46 AM, Glen Zorn wrote:

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).


If you say so, I believe you. Maybe I needed to read it again
(or better:-) but I found it a bit confusing. I guess if I were
paying enough attention to write code it might be fine. I could
also buy an argument that specifying home/visited appropriately
every time you say "domain name" might end up worse as well.


- 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?


On p18, the expected sequence number is not (yet) explained.
It is later though, in 5.4, so this is just me being v. picky.


- 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).


Lovely.


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.


Fair enough.

Cheers,
S.


- 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
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey