[radext] Comments on draft-wierenga-ietf-eduroam-00

["Jim Schaad" <[e-mail]>]

Remember you asked for it.

I am CC-ing the radext list for completeness not because I believe this
should be a radext working group document.

1.  It is not clear to me that the use of RFC 2119 language is appropriate
to a document that is describing what the current design is.

2.  Introduction: Suggest that the introduction should give a layout of the
document as well.   Specifically there are two ways to organize the second
half of the draft <problem, solution> or <problems><solutions> and it would
be good to set expectations of this upfront.

3.  Given that RFC 6614 and 6613 are experimental - do you want to say /IETF
standardization efforts/?

4.  Section 1.3 - Who has to be able to identify users? Just the IdP or the
NAS as well?  

5.  what does it mean to either impersonate someone or to take over their
identity?  If I give you my name and password it is possible for you to
impersonate me.  This language should be tightened.

6.  Do you really want me to be able to access your network or are you going
to provide a public network for me to be able to access and use?  It might
need to be clearer what is going on.  The first implies a greater degree of
identification that might actually exist.

7.  I can see three different vectors of scalability - it might be useful to
tease that out.  Users, Orgs providing access, Orgs hosting users.  Are the
last two a one-to-one or not?  

8.  For whom does it need to be easy to install and use - just clients or
organizations as well?  Can it be hard for an org to setup and still be easy
for clients?

9.  In the paragraph on security, I don't understand the purpose of the
first sentence.  This would tend to argue that secure is not an absolute
design goal.  There may be a trade off, but that would be a design goal of
usability which is separate.

10.  The goal is secure and privacy preserving - however there is nothing in
the text about who the privacy is supposed to be protected from.  While I
guess it could be the third part, that is hardly the limit of who one could
wish for privacy to be protected from.  Do you care about privacy from the
visited SP?  Should the IdP be able to know who the client is visiting?

11.  It is laid out that organizations should be able to set their own
authentication structure.  Is there going to be a minimum security that is
imposed on organizations by the eduroam federation?

12.  Were any other options considered for the architecture?  If so why were
they not used? 

13.  Section 2 - If you read the ABFAB architecture document, I think we
talk about three different trust relationships.  Two of which are
"pre-existing" and one of which is established during the protocol.  

14.  Going from the term type of trust to trust relationship does don't flow
well.

15.  The term establishment is potentially confusing in this location.  Are
you talking about for a single event or initial establishment (i.e.
introduction ) between the user and the IdP.

16.  Section 2.1 - I can understand that authentication uses EAP.  However
how does it use 802.1X and not use RADIUS for authentication?   If 802.1x
does anything other than carry EAP this should be covered.   Otherwise you
should probably include RADIUS here as well.

17.  Section 2.1.1 ?? wireless networks MUST support WPA2+AES - What does
this mean?  It is a requirement that all networks deploy this or merely that
the hardware has the capability to use it?  If a network deploys both WPA2
and WPA does that require that multiple SSIDs be used?  If so is there a
naming convention that is documented for this usage type?

18. What are the security implications of not knowing who the SP is - since
all SSIDs are "eduroam" it is not possible to distinguish from a user
perspective which are not to be used.

19.  Discuss the trade of for not always using "eduroam-foo" as the SSID

20.  Section 2.1.2 - What guidance is the federation giving on EAP methods -
is that of interest to this document?

21.  What is the "policy with regards to security properties"

22.  I don't understand the purpose of Figure 1 - It does not appear to be
reference from the text in any way.  The picture would seem to be
underspecified in that the specific protocols are not put any place (i.e.
X802.1x)  and the term EAP tunnel is not introduced in any manner.  As with
the ABFAB document I did like that it is not clear that the tunneled eap is
not traveling directly between the host and the authentication server.

23.  Note that mutual authentication does not imply privacy.  If I
authenticate with EAP-TLS and send both the server and the client
certificates in the clear then I have mutual authentication however I have
no privacy on identities.

24.  The term outer identity is problematic.  There is the EAP outer
identity - and then there is the RADIUS user-identity attribute.  The
routing is done on the later and it is generally (but not always) copied
from the initial EAP method.  However not all methods will have a distinct
inner identity.  Is there an identity that is transmitted on 802.1x that is
used rather than the first eap name?

25.  When did you suddenly say than a TLS tunnel was required.  If this is
true it should be stated someplace explicitly.  This is not a requirement on
IdPs that was not there before.  

26.  Do you want to say that outer identities must be NAIs or not?

27..  Section 2.2.1 - You just sprang a national server on me without
telling me what it represents.   Are you assuming that all routing is two
levels deep or  is there three and four level deep routing.  

28.  Do you want to say at this point who is operating the national servers
and root servers?   On what basis will they setup or remove shared secrets
with organizations?

29.  What are the trade offs of using [e-mail] vs @surnet.nl for
the outer identity?

30.  What, if anything needs to be said about the trust needed between the
access points and the organization RADIUS server.  Is this under some type
of protections?

31. Section 3 - Not all of the issues appear to be future problems that are
expected.  This paragraph should be expanded to say that current operations
have identified problems, in addition others are expected with an increase
of ...

32.  Section 3.1 - I think the word you are looking for is deduced rather
than deducted in many of these sentences.

33.  I have a slight problem with the fact that you are using down the
authentication path since you have just told me that it is a tree and thus
has both an up and a down component.  'Along' might be a better choice.

34.  I would not use the term proxy chain when looking at the length.  I
would just say that the radius authentication chain contains more than one
hop.   If there were no proxies then you have no problems, but in that case
the proxy chain is 0 hops? 1 hop?  Not clear.

35.  I assume that if a server which is believed to be "dead" sends you an
authentication request then you would also know that it is now live (step 3)

36.  One option that is not discussed here is the option of always flooding
and never assuming anything but realms fail.  What are the operational
problem with this approach.

37.  Presumably the use of TCP rather than UDP would also help this
situation.  Since you seem to be talking about ways that can be used to fix
this here.

38.  Section 3.2 - ? reactively or retroactively?

39.  You don't say how much improvements from section 3.1 would deal with
this issue.  If you could get reliable - don't fail because I did not get a
reply - does this help the situation in the event of no reply?

40.  What would be the security implications of being able to inject an
error code into the stream by a middle man?  Are they any worse than the
injection of an access-deny?

41.  Do you need to talk about dropped packets in this context as well as
dead servers?

42.  If 802.1x does not allow for returning errors.  Are you suggesting that
the RADIUS servers would inject EAP packets in the event of failures or
should this be handled by the NAS?

43.  Section 3.3 - You need to tell me what a ccTLD and a gTLD are

44.  What are the "downsides" to routing based on insertion of new
"national" servers that can talk directly to the org servers?   These
servers would potentially need to be more intelligent - but it would
restrict the places where tables need to be routed.  Was this considered?

45.  I am not sure that I understand why doing an add of a new route would
be especially error prone.  It seems that this should be easily fixable by a
simple tool.  Are you ever removing this from the table - it seems that this
would be overwhelmed by adds.  Are these mappings made at more than just the
root level - that is not clear from the discussion although I assume it
would be true.  

46.  Who are you imposing the recommendation on?  Is this a new 802.1x
requirement for an updated draft?  If so is this really what you want - or
do you want to be able to negotiate the L2 packet size all the way down?

47.  For whom are they hard to diagnose? Are you just talking about users or
are you talking about IT departments as well?  Are there recommendations on
how to do this diagnosis?

48.  Section 3.5 - Are EAP MSKs used in this configuration?  If so then you
have low level encryption on these and it could potentially be stolen and
used.

49.  It is not clear to me that using a pseudonymous client identifier for
the client does much of anything to prevent linking to an actual client.
You still can build a large mobility profile.

50.  You have not dealt with the issue for TLS of checking that the server
certificate is still valid.  This is also not currently done.

51.  Have you brought up the concept of an EAP configuration meta data
format in the EMU group?  It is about to close.

52.  Is there a reason why you don't reference RADIUS-TLS at this point as
this would deal with this issue to a certain extent.  I.e. no protection
from the proxies but from eavesdroppers.

53.  Section 4.1.1 - why is the translation not satisfactorily answered by
NASREQ?

54.  The last pargraph of 4.1.1. should be the first paragraph of 4.1.2

55.  Section 5 - It would seem that placing the policy enforcement with
Chargeable User Identity at the RADIUS server nearest the NAS - or at the
edge of the organization, would make as much sense as placing it on the NAS
itself.  This would allow for correlation between different access points
and given a better idea of abuse on the network as a whole.  Thus using the
servers that do this would solve the problem better.

56.  Section 5.1 - It may be also taken as evidence that you have no idea of
what is going on as you have not identified the serious incident as being
serious.

57.  Section 5.2 - How does the fact that the home site is now going have
the ability to block reflect back on the question of differences of opinion
on if the action was abuse or not?  What type of protocol is setup for
dealing with this type of request- is it automated, done by hand or through
the infrastructure?

58.  Section 5.3 - Given that home servers are required to regularly churn
CUIs, how does this affect the local accounting problems in terms of
tracking and preventing people from abusing the system.  Can the home IdP
simply deal with this issue by changing the CUI of an individual every time
an abuse is reported?



Random changes

s/Abfab/ABFAB/
s/in all continents/on all continents/
s/like for example/like/
s/alternative use/alternative uses/
s/foresaw/?????? - I am not sure what this sentence is supposed to say/

Update reference to privacy terminology draft - it is now
draft-iab-private-considerations