Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04

["Hoeper Katrin-QWKN37" <[e-mail]>]

MUST NOT be mandatory in combination with SHOULD be supported...sounds a
little bit odd to me!

We have good reasons to have the MUST NOT be mandatory.

Again, support is not excluded by this statement. 

Katrin

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Thursday, March 04, 2010 4:30 PM
> To: Hoeper Katrin-QWKN37
> Cc: Joseph Salowey; Dan Harkins; [e-mail]; Yaron Sheffer
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> 
>   Who said anything about making them mandatory? I just said SHOULD.
> 
>   Yes, Joe pointed out that the current MUST NOT language does not
> necessarily bar anyone from supporting them, but how do you then jump
> to the conclusion that saying they SHOULD be supported makes them
> mandatory?
> 
>   RFC 2119 says of SHOULD: "there may exist valid reasons in
particular
> circumstances [like the points I have been making] to ignore a
> particular item [like the admonitions to do server-side
authentication],
> but the full implications [potential loss of privacy] must be
understood
> and carefully weighed before choosing a different course." It does not
> indicate an absolute or mandatory requirement.
> 
>   Dan.
> 
> On Thu, March 4, 2010 1:30 pm, Hoeper Katrin-QWKN37 wrote:
> > I am absolutely against adding a SHOULD requirement for anonymous
> > tunnels.
> >
> > Dan you made your point that there are use cases where servers don't
> > have a certificate and don't use secret key credentials supported by
> > TLS.
> >
> > To make anonymous tunnels *mandatory* to support these corner cases
> > seems a bit far fetched considering that it would require a whole
list
> > of additional security requirements on the inner method.
> >
> > As Joe pointed out the current draft does not prohibit anonymous
> > tunnels, it just doesn't make them mandatory.
> >
> > I agree, that an extension to the base protocol is a much better
place
> > to discuss these use cases and the required additional limitations
on
> > the inner methods.
> >
> > Katrin
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> >> Joseph Salowey (jsalowey)
> >> Sent: Thursday, March 04, 2010 1:10 PM
> >> To: Dan Harkins
> >> Cc: [e-mail]; Yaron Sheffer
> >> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> >>
> >> I don't think it's appropriate to add a SHOULD for implementing
> >> anonymous cipher suites in this document.
> >>
> >> It is true that there is a MUST requirement for extensibility, but
I
> >> don't think we want to define the extensions in the base
> > specification.
> >> I don't think the current text limits what can be done in
extensions.
> >>
> >> Joe
> >>
> >> > -----Original Message-----
> >> > From: Dan Harkins [mailto:[e-mail]]
> >> > Sent: Thursday, March 04, 2010 8:50 AM
> >> > To: Joseph Salowey (jsalowey)
> >> > Cc: Yaron Sheffer; [e-mail]
> >> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> >> >
> >> >
> >> >   Hi Joe,
> >> >
> >> >   Section 3.8 has a MUST for "extensibility" which is explained
as:
> >> >
> >> >     "One example of a application for extensibility is credential
> >> >      provisioning.  When a peer has authenticated with EAP, this
is
> > a
> >> >      convenient time to distribute credentials to that peer that
may
> >> be
> >> >      used for later authentication exchanges."
> >> >
> >> > Now I believe EAP-FAST does this sort of thing for it's PAC
> >> provisioning
> >> > but it does anonymous TLS then EAP-MSCHAPv2 which has obvious
> >> problems.
> >> > So the need to do this sort of thing exists.
> >> >
> >> >   I know that one can do server-side authentication with some
> >> previously
> >> > installed certificate (and I know EAP-FAST has this as an option
> > too)
> >> but
> >> > _in practice_ that doesn't work so well which is why the most
> > popular
> >> > desktop and laptop operating system has a "do not verify server
> > cert"
> >> > check box on its EAP-TLS configuration GUI.
> >> >
> >> >   As I mentioned earlier security is about risk management and if
> > you
> >> > try to tell some guy deploying product that no he can't do what
he
> >> wants
> >> > to do because the authors of the IETF standard decided that it
> > wasn't
> >> > in his best interests he will find ways around those authors,
like
> >> instead
> >> > of installing a trusted cert he'll check the box to not verify
the
> >> server
> >> > cert that the authors said he has to use if he wants to use this
> >> product.
> >> > It would be much better to give him a tool that serves his
> > legitimate
> >> > needs and is easy for him to deploy and still maintains security
> >> (albeit
> >> > with a potential loss of privacy).
> >> >
> >> >   Would it be possible to add a reference in 4.2.1.1.3 that one
> > SHOULD
> >> > optionally implement an anonymous cipher suite?
> >> >
> >> >   Dan.
> >> >
> >> > On Thu, March 4, 2010 7:11 am, Joseph Salowey (jsalowey) wrote:
> >> > >> Joe, what Dan is proposing is a reasonable way to use a
one-time
> >> > > password
> >> > >> for the initial provisioning of a trust anchor. Initial
> >> provisioning
> >> > > is
> >> > >> important for many types of deployments. Does the document
allow
> > an
> >> > >> alternative secure way to do that?
> >> > >>
> >> > > [Joe] Initial provisioning is not currently in the scope of the
> >> document
> >> > > for the base method.  I agree that using anonymous cipher
suites
> > in
> >> the
> >> > > way Dan proposes can be used in a provisioning mechanism,
however
> >> there
> >> > > are other ways provisioning can be achieved with or without the
> > use
> >> of
> >> > > EAP.
> >> > >
> >> > >> Dan, I suspect that for this specific use case (one time use,
no
> >> need
> >> > > for
> >> > >> confidentiality), resistance against dictionary attack is not
> > very
> >> > >> important. So EAP-GPSK inside the tunnel will do just as well.
> >> > >>
> >> > >> Thanks,
> >> > >> 	Yaron
> >> > >>
> >> > >> > Date: Wed, 3 Mar 2010 20:05:09 -0800
> >> > >> > From: "Joseph Salowey (jsalowey)" <[e-mail]>
> >> > >> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> >> > >> > To: "Dan Harkins" <[e-mail]>,	"Hoeper
> > Katrin-QWKN37"
> >> > >> > 	<[e-mail]>
> >> > >> > Cc: [e-mail]
> >> > >> > Message-ID:
> >> > >> > 	<AC1CFD94F59A264488DC2BEC3E890DE509BD3EBA@xmb-sjc-
> >> > >> > 225.amer.cisco.com>
> >> > >> > Content-Type: text/plain;	charset="us-ascii"
> >> > >> >
> >> > >> > Hi Dan,
> >> > >> >
> >> > >> > The document currently states anonymous cipher suites MUST
NOT
> > be
> >> > >> > mandatory to implement for the tunnel method.  I think the
is
> > the
> >> > >> > appropriate stance for the document to take for the base
tunnel
> >> > > method.
> >> > >> > I also do not think this prevents a follow-on specification
> >> defining
> >> > >> > how
> >> > >> > to use anonymous tunnel securely.
> >> > >> >
> >> > >> > Cheers,
> >> > >> >
> >> > >> > Joe
> >> > >> >
> >> > >>
> >> > >> _______________________________________________
> >> > >> Emu mailing list
> >> > >> [e-mail]
> >> > >> https://www.ietf.org/mailman/listinfo/emu
> >> > > _______________________________________________
> >> > > Emu mailing list
> >> > > [e-mail]
> >> > > https://www.ietf.org/mailman/listinfo/emu
> >> > >
> >> >
> >>
> >> _______________________________________________
> >> Emu mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/emu
> >
>