Re-, Please don't turn this discussion into "draft-ietf-intarea-nat-reveal-analysis is against authentication mechanisms".
Implicit identification is only on use case targeted by the HOST_ID idea. I offered you the opportunity to introduce text (see the proposal below) to educate readers that explicit means are more robust but you rejected my offer. Cheers, Med >-----Message d'origine----- >De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >Envoyé : jeudi 26 juillet 2012 11:09 >À : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >Objet : Re: [Int-area] Comments on >draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Mohamed, > >I know that RFC 6269 just tries to identify what the authors >consider as broken in real world deployments. The analysis in >that document is, however, used as a justification for doing >the work on draft-ietf-intarea-nat-reveal-analysis-02. > >As it turns out there are other ways to fix these problems, >particularly with respect to authentication. Not only are >these mechanisms less brittle but they also provide better >properties from a security and privacy point of view. > >That's maybe the reason why your co-workers had been active in >standardization on these security mechanisms for a long time >(pointer to the work on SAML). > >I had, however, jumped into the discussion because of the >statement that users are outside the scope of this work which >I believe is incorrect. > >Ciao >Hannes > >On Jul 26, 2012, at 11:33 AM, <mohamed.boucad...@orange.com> wrote: > >> Dear Hannes, >> >> RFC6269 does not promote any mechanism but rather it >identifies what is broken in real deployments. >> >> Saying that, do you think it is useful to re-insert the text >we had in earlier version: >> >> Enabling explicit identification means and adequate >security suite is >> more robust than relying on source IP address or HOST_ID. But >> tension may appear between strong privacy and usability >(see Section >> 4.2 of [I-D.iab-privacy-workshop]). >> >> Cheers; >> Med >> >>> -----Message d'origine----- >>> De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >>> Envoyé : jeudi 26 juillet 2012 09:52 >>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >>> Objet : Re: [Int-area] Comments on >>> draft-ietf-intarea-nat-reveal-analysis-02 >>> >>> Hi Mohamed, >>> >>> On Jul 26, 2012, at 10:30 AM, <mohamed.boucad...@orange.com> wrote: >>> >>>>> But aside from that, I disagree with you on purpose of whatever is >>>>> being attempted here. The document is about identifying >hosts, and >>>>> you mention "users". These are not the same thing. Which >>> do you want >>>>> to identify? In my opinion, anything related to users (and >>> not hosts) >>>>> should be completely out of scope. >>>> >>>> Med: Agreed. The notion of "user" is out of scope of >>> draft-ietf-intarea-nat-reveal-analysis. >>> >>> >>> It would be nice if that would actually be true. >>> >>> Just an example from Section 13.2 of RFC 6269 >>> http://tools.ietf.org/html/rfc6269#section-13 >>> >>> " >>> Simple address-based identification mechanisms that are used to >>> populate access control lists will fail when an IP address is no >>> longer sufficient to identify a particular subscriber. >>> " >>> >>> Hint: >> particular subscriber << >>> >>> During the Taipei presentation I had complained about >>> promoting inadequate (or historic) security mechanisms for >>> user authentication already. >>> >>> The IETF has developed technology to provide cryptographic >>> authentication (at all layers) already since 20 years. >>> >>> Ciao >>> Hannes >>> > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
