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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Hi Jim,

On 28 mrt. 2013, at 23:44, "Jim Schaad" <[e-mail]> wrote:

> Remember you asked for it.

Be careful what you wish for, you may get it....

But seriously, thanks a lot for your careful review, many of the points you bring up stem from the fact that we are too familiar with the architecture and thus assume knowledge, so your review is very helpful in pointing those out. Some other comments need some more careful consideration, we'll work on addressing those.

Thanks again!

Klaas

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