RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

[Glen Zorn]

Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] writes:
 
> I object to this document being published as a Proposed Standard.  When
> this document was discussed in the EMU meeting at IETF-71 there was
> much
> concern raised with respect to existing IPR in the area of secure
> password methods used by this draft.  Additionally, soon after its
> initial publication and announcement on the CFRG list, flaws were found
> with the draft.  The authors were very responsive in addressing the
> issues, but this points out that the algorithms used in this draft have
> had less review than other secure password mechanisms developed over
> the
> years.  Another approach to a secure password only EAP method, EAP-EKE,
> has been proposed in draft-sheffer-emu-eap-eke-02.  This method is
> based
> on EKE, which is already in use, has a long history of review, and has
> much better understood IPR considerations.  Given that there is an
> alternative to consider I do not support publishing EAP-PWD in the
> standards track.

IMHO, this question is orthogonal (& largely immaterial) to the one at hand.
It's one thing for the IETF to reach consensus that the draft be
Informational; it is a completely different thing for the publication path
to be changed without either notification of (other than the Last Call
announcement itself) or consultation with the authors.  If this was _not_ a
simple error, then the action was arbitrary & capricious, not to mentioned
underhanded & must certainly be considered as grounds for dismissal of the
(as yet unnamed) person or persons responsible, unless the IETF has recently
converted to an authoritarian regime.  As an aside, it seems that
draft-green-secsh-ecc has suffered the same fate, suggesting that this is
neither an error nor an isolated occurrence.

...

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

[Robert Elz]

Date:Wed, 22 Jul 2009 08:32:38 +0200
From:Harald Alvestrand 
Message-ID:  <4a66b286.9080...@alvestrand.no>

I don't want to say much more on this issue, I suspect enough has
been said now, but just one final (from me) point ...

  | The working group's non-consensus on this point is documented in section 
  | 4.4 of RFC 5377:
  | 
  | 4.4.  Rights Granted for Use of Text from IETF Contributions
  | 
  |There is no consensus at this time to permit the use of text from
  |RFCs in contexts where the right to modify the text is required.  The
  |authors of IETF Contributions may be able and willing to grant such
  |rights independently of the rights they have granted to the IETF by
  |making the Contribution.

I have no idea how to interpret that - one meaning might be that
contributors of code to the IETF can assume that the IETF will not
grant rights that allow modification of the text.   If that's how it
works out, then once again, whatever you think other parts of the
RFC say, contributors can rely upon that, and then the IETF cannot
later change its mind, and allow modification - the contributor gave
the code based upon the assumption that would not be permitted.

On the other hand, if we're all convinced that the contributor must be
giving the IETF the rights to do whatever it likes with the contribution,
including permitting modifications - then the IETF should be (and by
referring to a BSD like licence, in fact, is) allowing people do do
whatever they want with code in an RFC - which includes modifying it.

After all "there is no consensus to permit" also can be written with
the exact same meaning as "there is no consensus not to permit", that's
what "no consensus" means (though authors sometimes try to describe a
point where there's no agreement at all to make it look as if the result
of that should be what they think the outcome should be - which is what
the paragraph you quoted looks like to me.   That is, we couldn't get
people to agree to prohibit modifications, so we'll write a paragraph
that makes it look like the base position is to prohibit that, and then
make it clear that we didn't agree that distribution with modification
rights should be allowed - everyone will just conclude that it isn't
allowed...

That's bogus, and it looks to me (by use of the BSD licence, which if
the advertising clause were removed, which it should be (and is in the
current version of the BSD licence) about as liberal as it is possible to be.
That is, I cannot see it is possible to be more liberal (advertising
excepted, and that's a minor point) than the BSD licence which is being
specified.

Making it truly difficult to change makes it harder for the distribution
to be made more restricted, which looks to me to be just about the only
way it is possible to move (and if the advertising clause has been, or can
be quicky, removed from the IETF's version of the BSD licence, then we're
about as unrestricted as it is possible to get).

On the other hand, if the IETF's "BSD licence" is currently prohibiting
modifications, then it clearly is not a BSD licence at all (so you'd be
right, that name ought to be removed as being misleading) - and that ought
to be fixed, as quoted above (being read carefully) we have no consensus
to prohibit distribution with modifications permitted (unless the
contributors are not granting that right, of course) so we may as well
just allow modifications.

kre

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Eric Rescorla]

At Wed, 22 Jul 2009 09:59:38 +,
Florian Weimer wrote:
> Anyway, those who object to the ECC infection should strive to remove
> it from the base TLS spec.  It doesn't make sense to rehash this
> discussion over and over again, for each draft produced by the WG
> which happens to be compatible with ECC algorithms and for which
> Certicom files an IPR claim.

Note: ECC isn't in the base spec, really. 

More precisely, the code points are defined in 4492. 

All the ECC that's defined in 5246 is the rules for what sorts of
certificates may be used for a given algorithm, and that's because
5246 changed the rules beyond 4346 and so we wanted to have them all
in one place.

-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP Requirements)toProposed Standard

[Tom.Petch]

- Original Message -
From: "Adrian Farrel" 
To: "Tom.Petch" 
Cc: "ietf" 
Sent: Tuesday, July 21, 2009 11:36 PM
Subject: Re: Last Call: draft-ietf-mpls-tp-requirements (MPLS-TP
Requirements)toProposed Standard


> Hi Tom,
>
> >> > a) The security section of this I-D says
> >> > see[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
> >> > which is an informative reference.
> >> >
> >> > I believe that security should be normative, not informative, even in
> >> > this, a
> >> > requirements (as opposed to a protocol) draft.
> >>
> >> I hear you. Security is fundamental.
> >>
> >> draft-ietf-mpls-mpls-and-gmpls-security-framework is targetted as an
> >> informational RFC because it does not define any protocol mechanisms. It
> >> is
> >> a catalog of existing protocol security mechanisms and reports the
> >> current
> >> state of the art.
> >>
> >> In the light of this, do you believe it is necessary to create a downref
> >> from a requirements document to an informational document?
> >>
> >> Could this be handled by strenghtening the text in the security
> >> requirements
> >> section?
> >
> > I don't see a good solution to this. I think the text should be
> > strengthened; at
> > present, it seems a little casual, not quite serious enough.  The
> > referenced I-D
> > is massive, contains much that I suspect will not be relevant to MPLS-TP
> > and
> > seems an unsatisfactory companion to this I-D.  I think that
> > draft-mpls-tp-oam-requirements does a much better job here, and would like
> > to
> > see something similar, highlighting the key threats (and for MPLS-TP, I do
> > not
> > know what they are:-(
>
> As luck would have it, a couple of people have just posted
> draft-fang-mpls-tp-security-framework-00.txt
>
> This is in early days, but I think that draft-ietf-mpls-tp-requirements
> should be able to defer to it for security in the same non-normative way
> that it defers to draft-mpls-tp-oam-requirements for OAM and
> draft-mpls-tp-nm-requirements for network management.

OK

Tom Petch

> Cheers,
> Adrian
>
> >> > b) The terminology section of this draft overlaps with that in an
> >> > Informational
> >> > Reference [I-D.helvoort-mpls-tp-rosetta-stone] "A Thesaurus for the
> >> > Terminology
> >> > used in MPLS-TP drafts/RFCs and  ITU-T's Transport Network
> >> > Recommendations."
> >> > (now republished as a Working Group Draft)
> >> > which will doubtless progress to an RFC but as Informational.  I see
> >> > this
> >> > as
> >> > problematic; the two may be in step now but I am doubtful that they
> >> > will
> >> > be as
> >> > and when this last gets amended in the course of its development.  The
> >> > mpls-tp
> >> > list has seen some vigorous debate already about the meaning of terms
> >> > (eg
> >> > associated bidirectional, AIS).  Sometimes, the same concept has a
> >> > different
> >> > term in IETF versus ITU-T (versus IEEE) while the same term may also be
> >> > used for
> >> > a different concept.
> >> >
> >> > RFC4397 is the product of a similar, earlier issue and is another
> >> > potential
> >> > overlap.
> >> >
> >> > The definitions in this I-D may be normative for this I-D but if they
> >> > diverge from definitions in other I-Ds, we are storing up problems for
> >> > the
> >> > future.
> >> >
> >> > On balance, I believe that this rosetta-stone should be a Normative
> >> > Reference,
> >> > ideally removing the overlapping definitions.
> >>
> >> You are right, of course, that terminology needs to be consistent. But
> >> making a normative reference to the Rosetta Stone draft would put us into
> >> a
> >> nasty non-publication loop because that draft can't be published until
> >> everything else is completely stable, and nothing else can be published
> >> with
> >> a normative reference to an unpublished I-D.
> >>
> >> Would it work for the authors to take a long hard look at the terms they
> >> have to:
> >> 1. make sure they only define terms they really need and cannot defer
> >>to the Rosetta Stone
> >> 2. ensure the Rosetta Stone is up-to-date and includes pointers out to
> >>the initial definitions so that the terms do not get updated in the
> >> future?
> >
> > That sounds like a viable solution.  My sense is that because this has
> > come
> > first, or at least early on, it has accumulated definitions it does not
> > need.
> > Technically, I fear we will regret not producing the Rosetta Stone first,
> > but
> > politically, I suspect that that is unrealistic and so we have to do as
> > you
> > suggest.
>
>

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

[John Leslie]

Harald Alvestrand  wrote:
> 
> The working group's non-consensus on this point is documented in section 
> 4.4 of RFC 5377:
>...

   ... of historical interest only, IMHO...
 
> The "RFC 5378" license to the trust allows, for instance, the Trust to 
> grant the right of copying small snippets of code without attaching the 
> full BSD license to them. The current TLP does not give that right.

   This is getting awfully deep into IANAL territory.

   Since IANAL and I don't want to play one on TV, let me shift the focus
away from whether that distinction entails a difference -- to the question
of whether opening a discussion of such details tends to clarify or
confuse.

   IMHO, it tends to confuse far more than it clarifies.

> Incoming and outgoing rights for code are currently different.

   Likewise, discussing that difference, IMHO, tends to confuse far more
than it clarifies.

> I'm fairly convinced that there will come a time when we need to 
> relicense text that was previously licensed by the Trust in a way that 
> is more liberal than the current text of the TLP allows for (while 
> remaining within the scope of rights granted to the trust).

   May I suggest that many of us don't share this conviction?

   May I also suggest that opening such a question (where the IPR WG
couldn't reach consensus) doesn't seem terribly likely to find any quick
consensus?

   May I suggest that punting such a question to some future group of
Trustees to decide for us is even less likely to find a quick consensus?

   IETF participants admittedly tend towards paranoia. We should accept
this and avoid things which feed their paranoia. We should especially
(IMHO) avoid things that feed their paranoia with exactly the same food
as a previous round.

   Please, Harald, do us a favor and accept the "BSD" license as "good
enough" for the "forseeable" future. Yes, we can all imagine scenarios
where something else would be "better", but we'd like to put something
to bed here so that RFC publication can stop stumbling over "license"
questions.

> That's why I yell so much on this matter.

   Your opinion is noted. You have our permission to say, "I told you so!"
when/if we're proven wrong.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

[John Leslie]

Glen Zorn  wrote:
> Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] writes:
>  
>> I object to this document being published as a Proposed Standard.  When
>> this document was discussed in the EMU meeting at IETF-71 there was
>> much concern raised with respect to existing IPR...
> 
> IMHO, this question is orthogonal (& largely immaterial) to the one at hand.

   Agreed.

> It's one thing for the IETF to reach consensus that the draft be
> Informational; it is a completely different thing for the publication path
> to be changed without either notification of (other than the Last Call
> announcement itself) or consultation with the authors.

   Lack of consultation with the authors would be unfortunate.

> If this was _not_ a simple error, then the action was arbitrary &
> capricious, not to mentioned underhanded & must certainly be considered
> as grounds for dismissal of the (as yet unnamed) person or persons
> responsible,

   I do not agree. At most, an apology might be required.

> unless the IETF has recently converted to an authoritarian regime.

   There is nothing "recent" about this. To be considered by the IESG,
there must be a sponsoring Area Director for any Individual Submission.
That Area Director has always had full authority to decide whether to
LastCall as Informational or Proposed Standard.

> As an aside, it seems that draft-green-secsh-ecc has suffered the same
> fate, suggesting that this is neither an error nor an isolated occurrence.

   Exactly!

   (You technically have the right to appeal the decision to LastCall as
Informational; but the Area Director will always have the right to
decline to sponsor publication as Proposed Standard.)

   The difference may not be as great as you seem to think. Appeal if
you must, but it's really not unusual to change "proposed status" as
a result of LastCall comments. It might be more helpful to simply post
(polite) LastCall comments of your own about why "Proposed Standard"
would be more appropriate than "Informational".

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Simon Josefsson]

With the caveat that I have recently returned from vacation, and
consequently may have missed some clarifications or paged out some
context:

If the #1154 IPR disclosure is the final word from Certicom on this
document, I don't support advancing this document on the standards
track.  My concern remains that Certicom claims they have IPR that
covers the document -- that is what the #1154 disclosure says (section
IV).  The additional information provided in the PDF is not helping: it
grants a license for use together with ECC.  It doesn't say anything
about the use without ECC.

The way I see it, TLS implementers and the broader Internet does not
gain something significant by having this document published.  Other
IETF documents can use the TLS PRF to derive keying material.  On the
contrary, it seems both TLS implementers and the broader Internet
community would be hurt by publishing the document since having patent
threats looming over widely used techniques has stability and
interoperability impacts.

I recall that Certicom was positive about clarifying their intentions so
maybe we can continue that discussion and get something more useful than
the recent disclosure.

Speaking as TLS implementer of the document and document [1] author that
reference this document,
/Simon

[1] http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02

The IESG  writes:

> The IESG has received a request from the Transport Layer Security WG 
> (tls) to consider the following document:
>
> - 'Keying Material Exporters for Transport Layer Security (TLS) '
> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16821&rfc_flag=0
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

[Joseph Salowey (jsalowey)]

While I see that draft-ietf-tls-extractor is listed in section IV of
#1154 IPR disclosure as related material,  I see that it is explicitly
not listed in section V part C which lists what is specifically covered
by the disclosure.  I don't think Certicom is claiming IPR on
draft-ietf-tls-extractor because it is not among the list of documents
in section V.   

Joe

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
> Behalf Of Simon Josefsson
> Sent: Wednesday, July 22, 2009 12:32 PM
> To: ietf@ietf.org; t...@ietf.org
> Subject: Re: Last Call: draft-ietf-tls-extractor (Keying 
> Material Exportersfor Transport Layer Security (TLS)) to 
> Proposed Standard
> 
> With the caveat that I have recently returned from vacation, 
> and consequently may have missed some clarifications or paged out some
> context:
> 
> If the #1154 IPR disclosure is the final word from Certicom 
> on this document, I don't support advancing this document on 
> the standards track.  My concern remains that Certicom claims 
> they have IPR that covers the document -- that is what the 
> #1154 disclosure says (section IV).  The additional 
> information provided in the PDF is not helping: it grants a 
> license for use together with ECC.  It doesn't say anything 
> about the use without ECC.
> 
> The way I see it, TLS implementers and the broader Internet 
> does not gain something significant by having this document 
> published.  Other IETF documents can use the TLS PRF to 
> derive keying material.  On the contrary, it seems both TLS 
> implementers and the broader Internet community would be hurt 
> by publishing the document since having patent threats 
> looming over widely used techniques has stability and 
> interoperability impacts.
> 
> I recall that Certicom was positive about clarifying their 
> intentions so maybe we can continue that discussion and get 
> something more useful than the recent disclosure.
> 
> Speaking as TLS implementer of the document and document [1] 
> author that reference this document, /Simon
> 
> [1] 
> http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02
> 
> The IESG  writes:
> 
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document:
> >
> > - 'Keying Material Exporters for Transport Layer Security (TLS) '
> > as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, 
> and solicits 
> > final comments on this action.  Please send substantive comments to 
> > the ietf@ietf.org mailing lists by 2009-08-10. 
> Exceptionally, comments 
> > may be sent to i...@ietf.org instead. In either case, please retain 
> > the beginning of the Subject line to allow automated sorting.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt
> >
> >
> > IESG discussion can be tracked via
> > 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa
> > g=16821&rfc_flag=0
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

[Simon Josefsson]

Let's go back to RFC 3979:

  6.4.  What Must be in a Disclosure?

  6.4.1.  The disclosure must list the numbers of any issued patents or
   published patent applications or indicate that the claim is based on
   unpublished patent applications.  The disclosure must also list the
   specific IETF or RFC Editor Document(s) or activity affected.

The "draft-ietf-tls-extractor-06" name is mentioned in the disclosure.

For what it's worth, the PDF referenced in the disclosure also mentions
draft-ietf-tls-extractor-06.

Together, I can't read this in any other way that Certicom believes they
have some patents covering draft-ietf-tls-extractor-06 and have followed
the RFC 3979 rules and informed the IETF about this.

If Certicom didn't intend to claim they believe they own patents that
they believe covers draft-ietf-tls-extractor-06 they need to supersede
the disclosure with one that does not mention that document.

The reason for this situation may be the poor terminology used by the
IETF IPR web pages.  I understand and appreciate that Certicom has tried
to clarify the situation, but to me the updated form does not improve
the situation.  Perhaps Certicom would be able to more easily create a
disclosure that matches RFC 3979 rules if the web pages were improved.

/Simon

"Joseph Salowey (jsalowey)"  writes:

> While I see that draft-ietf-tls-extractor is listed in section IV of
> #1154 IPR disclosure as related material,  I see that it is explicitly
> not listed in section V part C which lists what is specifically covered
> by the disclosure.  I don't think Certicom is claiming IPR on
> draft-ietf-tls-extractor because it is not among the list of documents
> in section V.   
>
> Joe
>
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 
>> Behalf Of Simon Josefsson
>> Sent: Wednesday, July 22, 2009 12:32 PM
>> To: ietf@ietf.org; t...@ietf.org
>> Subject: Re: Last Call: draft-ietf-tls-extractor (Keying 
>> Material Exportersfor Transport Layer Security (TLS)) to 
>> Proposed Standard
>> 
>> With the caveat that I have recently returned from vacation, 
>> and consequently may have missed some clarifications or paged out some
>> context:
>> 
>> If the #1154 IPR disclosure is the final word from Certicom 
>> on this document, I don't support advancing this document on 
>> the standards track.  My concern remains that Certicom claims 
>> they have IPR that covers the document -- that is what the 
>> #1154 disclosure says (section IV).  The additional 
>> information provided in the PDF is not helping: it grants a 
>> license for use together with ECC.  It doesn't say anything 
>> about the use without ECC.
>> 
>> The way I see it, TLS implementers and the broader Internet 
>> does not gain something significant by having this document 
>> published.  Other IETF documents can use the TLS PRF to 
>> derive keying material.  On the contrary, it seems both TLS 
>> implementers and the broader Internet community would be hurt 
>> by publishing the document since having patent threats 
>> looming over widely used techniques has stability and 
>> interoperability impacts.
>> 
>> I recall that Certicom was positive about clarifying their 
>> intentions so maybe we can continue that discussion and get 
>> something more useful than the recent disclosure.
>> 
>> Speaking as TLS implementer of the document and document [1] 
>> author that reference this document, /Simon
>> 
>> [1] 
>> http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02
>> 
>> The IESG  writes:
>> 
>> > The IESG has received a request from the Transport Layer Security WG
>> > (tls) to consider the following document:
>> >
>> > - 'Keying Material Exporters for Transport Layer Security (TLS) '
>> > as a Proposed Standard
>> >
>> > The IESG plans to make a decision in the next few weeks, 
>> and solicits 
>> > final comments on this action.  Please send substantive comments to 
>> > the ietf@ietf.org mailing lists by 2009-08-10. 
>> Exceptionally, comments 
>> > may be sent to i...@ietf.org instead. In either case, please retain 
>> > the beginning of the Subject line to allow automated sorting.
>> >
>> > The file can be obtained via
>> > http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt
>> >
>> >
>> > IESG discussion can be tracked via
>> > 
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa
>> > g=16821&rfc_flag=0
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard

[Joseph Salowey (jsalowey)]

I agree with Simon that the IETF's disclosure page could use some work,
it seems rather confusing and it is not consistently filled out.

Comments inline below:   

> If your interpretation were correct, then we would have to 
> say that Certicom is not claiming IPR on _any_ IETF 
> document---draft or RFC---since none are listed in Section V. 
> But I think that is obviously incorrect---I think you have 
> misinterpreted what should be in which section.
>

[Joe] Are we both looking at https://datatracker.ietf.org/ipr/1154/?  In
section V I see several documents listed:

"RFC 3278, RFC 4109, RFC 4492, RFC 4753, RFC 4754, RFC 4869, RFC 5008,
RFC 5289, draft-rescorla-tls-suiteb-12, draft-green-secsh-ecc-07,
draft-igoe-secsh-suiteb-00, draft-ietf-smime-3278bis-07,
draft-ietf-smime-sha2-11"

> Section titles and descriptions: 
> 
>  Section IV. IETF Document or Other Contribution to Which 
> this IPR  Disclosure Relates: 
> 
>  Section V. Disclosure of Patent Information (i.e., patents 
> or patent  applications required to be disclosed by Section 6 
> of RFC 3979)
> 
> Section IV lists the drafts and RFCs.  Section V lists the patents.  
> One would not expect to find a draft or RFC listed in Section 
> V, nor a patent listed in Section IV.
> 
> Extractor and other documents are listed in section IV. 
> 

[Joe] Section V also has a sub-section C, which allows you to specify
what parts of IETF documents are covered by the patent information
disclosed in section V.  This section lists several documents which is a
subset of what is mentioned in section IV.  This seems straight forward
to me.  

Joe
>   --Dean
> 
> On Wed, 22 Jul 2009, Joseph Salowey (jsalowey) wrote:
> 
> > While I see that draft-ietf-tls-extractor is listed in section IV of
> > #1154 IPR disclosure as related material,  I see that it is 
> explicitly 
> > not listed in section V part C which lists what is specifically 
> > covered by the disclosure.  I don't think Certicom is 
> claiming IPR on 
> > draft-ietf-tls-extractor because it is not among the list 
> of documents
> > in section V.   
> > 
> > Joe
> > 
> > > -Original Message-
> > > From: ietf-boun...@ietf.org 
> [mailto:ietf-boun...@ietf.org] On Behalf 
> > > Of Simon Josefsson
> > > Sent: Wednesday, July 22, 2009 12:32 PM
> > > To: ietf@ietf.org; t...@ietf.org
> > > Subject: Re: Last Call: draft-ietf-tls-extractor (Keying Material 
> > > Exportersfor Transport Layer Security (TLS)) to Proposed Standard
> > > 
> > > With the caveat that I have recently returned from vacation, and 
> > > consequently may have missed some clarifications or paged out some
> > > context:
> > > 
> > > If the #1154 IPR disclosure is the final word from 
> Certicom on this 
> > > document, I don't support advancing this document on the 
> standards 
> > > track.  My concern remains that Certicom claims they have 
> IPR that 
> > > covers the document -- that is what the
> > > #1154 disclosure says (section IV).  The additional information 
> > > provided in the PDF is not helping: it grants a license for use 
> > > together with ECC.  It doesn't say anything about the use without 
> > > ECC.
> > > 
> > > The way I see it, TLS implementers and the broader 
> Internet does not 
> > > gain something significant by having this document 
> published.  Other 
> > > IETF documents can use the TLS PRF to derive keying material.  On 
> > > the contrary, it seems both TLS implementers and the broader 
> > > Internet community would be hurt by publishing the document since 
> > > having patent threats looming over widely used techniques has 
> > > stability and interoperability impacts.
> > > 
> > > I recall that Certicom was positive about clarifying their 
> > > intentions so maybe we can continue that discussion and get 
> > > something more useful than the recent disclosure.
> > > 
> > > Speaking as TLS implementer of the document and document 
> [1] author 
> > > that reference this document, /Simon
> > > 
> > > [1]
> > > 
> http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02
> > > 
> > > The IESG  writes:
> > > 
> > > > The IESG has received a request from the Transport 
> Layer Security 
> > > > WG
> > > > (tls) to consider the following document:
> > > >
> > > > - 'Keying Material Exporters for Transport Layer 
> Security (TLS) '
> > > > as a Proposed Standard
> > > >
> > > > The IESG plans to make a decision in the next few weeks,
> > > and solicits
> > > > final comments on this action.  Please send substantive 
> comments 
> > > > to the ietf@ietf.org mailing lists by 2009-08-10.
> > > Exceptionally, comments
> > > > may be sent to i...@ietf.org instead. In either case, please 
> > > > retain the beginning of the Subject line to allow 
> automated sorting.
> > > >
> > > > The file can be obtained via
> > > > 
> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.tx
> > > > t
> > > >
> > > >
> > > > IESG discussion can be tracked via
> > > > 
> > > 
> https:

Comment on TLP revisions re non-IETF documents

[Brian E Carpenter]

This may seem like a small comment but I believe it is important.
We know that we have an issue to resolve collectively, namely the
IPR regimes for non-IETF stream documents. We probably agree that
(as the revised TLP says or implies) it is for each stream individually
to decide whether it accepts none, some or all of the IETF rules
and the IETF Trust's legal provisions.

However, Clause 2.f.i of the draft revised TLP includes the
statement "The IETF Trust does not determine the legal rules that
apply to documents in Alternate Streams."

I would like to see that changed to "The IETF Trust does not
*currently* determine the legal rules that apply to documents in
Alternate Streams."

Rationale: some of the other streams might choose to request the
Trust to do so. (Or they might not; I don't know.)

I have re-read the "Purpose" clause of the Trust Agreement, and
it has the flexibility to allow the Trust to do this, if so
requested and agreed. We shouldn't remove that flexibility.

There are other issues in this area, but John Klensin's appeal
already addresses them.

Regards
   Brian Carpenter
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC

[Dan Harkins]

  Hi John,

On Wed, July 22, 2009 10:27 am, John Leslie wrote:
>The difference may not be as great as you seem to think. Appeal if
> you must, but it's really not unusual to change "proposed status" as
> a result of LastCall comments. It might be more helpful to simply post
> (polite) LastCall comments of your own about why "Proposed Standard"
> would be more appropriate than "Informational".

  You make a very good suggestion. So let me make some Last Call
comments of my own about why "Proposed Standard" is more appropriate
that "Informational".

  Shared keys (including passwords) are the preeminent access method for
the Internet today. EAP is a very popular protocol for providing network
access. I believe the Internet community needs to recommend a way to
_securely_ use this wildly popular credential in this hugely popular
authentication protocol.

  An Informational RFC is published just for the general information of
the Internet community and does not represent a recommendation of the
Internet community. So Informational doesn't seem like the right level.

  The importance of this subject, and the need to have a recommendation
by the Internet community, can be seen by the fact that a Standards Track
RFC already exists to use shared keys in EAP, RFC5433, but it is insecure
and is vulnerable to passive dictionary attack. Therefore I believe it
is necessary to recommend a way to use shared keys securely; it is
necessary to publish another RFC at the same level as RFC5433 that does
not have the flaws of RFC5433.

  It would not make much sense to have the Internet community recommend
an insecure way of using shared keys with EAP and then publish a secure
way of using shared keys with EAP merely for edification purposes only.
No, a Standards Track RFC is really needed.

  As Joe Salowey noted, there is another draft that specifies use of
the Encrypted Key Exchange (EKE) as an EAP method. Unfortunately, that
protocol must define its own special finite cyclic groups, and it cannot
use finite cyclic groups based on elliptic curve cryptography, or it will
suffer from the same flaw as RFC5433. EAP-pwd can use any of the two
score or so finite cyclic groups defined by for use in IKE and TLS,
both elliptic curve groups and, more traditional, groups based on
exponentiation modulo a large prime number. These groups have seen broad
use and received scrutiny by the academic and cryptographic community,
so it is important to use them and not "roll your own". EAP-pwd is a much
more general purpose solution to the problem and is, in my opinion, a
better candidate for recommendation.

  EAP-pwd has received about as much scrutiny as it can in the IETF.
When presented at an EMU meeting it received quite a bit of interest
but was ruled out-of-scope due to EMU's charter. There were also concerns
that there was no definitive statement that EAP-pwd was not IPR encumbered
(which is nearly impossible to provide anyway). There is community interest
in secure shared-secret authentication with EAP and EAP-pwd provides that.

  To sum, I think the Internet community must recommend a way to use
shared keys (including passwords) securely with EAP (RFC5433 does not
recommend a _secure_ way to use them); it must publish an RFC at the
Standards Track level. And EAP-pwd is the best choice to do that because
it is a more robust and general purpose solution that EAP-EKE.

  I would like to hear other comments on this topic (with the exception
of those over the irrelevant topic of IPR-- for which there is none in
this draft). Why shouldn't it be a Proposed Standard?

  best regards,

  Dan.



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Proposed Standard

[Bernard Aboba]

I would like to comment on the process aspect of this IETF last call.  A 
subsequent post will provide comments on the protocol. 

 

Overall, I believe that the appropriate process for handling this document is 
not to bring it to IETF last call as an individual submission, but rather to 
charter a work item within an IETF WG.  

 

There are two current EAP method drafts that are based on zero-knowledge 
algorithms:

1. http://tools.ietf.org/html/draft-harkins-emu-eap-pwd (this document)

2. http://tools.ietf.org/html/draft-sheffer-emu-eap-eke

 

Previously there was also an EAP method submission utilizing SRP:

3. http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03

 

All three of these documents were slated for inclusion on the IETF standards 
track. 

 

Given the number of EAP method RFCs that have already been published, I do not 
believe that it serves the Internet community for the IETF to publish multiple 
EAP method specifications of a similar genre on the Standards Track, while 
bypassing the WG process.  

 

If the standardization of zero-knowledge algorithms is an important area of 
work for the IETF (and I believe this to be true), then work in this area 
should be chartered as a working group work item, with the goal to select a 
single method for standardization.  Prior to the EMU WG re-charter, Dan Harkins 
made an argument for chartering of work in this area.  His arguments were sound 
then, and they are (even more) sound today.  However, Dan did not succeed in 
getting the work added to the EMU WG charter.  It is time for the IESG to 
re-consider its decision to delay standardization of zero knowledge algorithms, 
which was made in the earlier part of the decade.  If the EMU WG is not 
suitable for handling this work, then another security area WG should be 
created for the purpose.  

 

 

 

 

 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Proposed Standard

[Glen Zorn]

Bernard Aboba [mailto://bernard.ab...@hotmail.com]
  writes:

I would like to comment on the process aspect of this IETF last call.  A
subsequent post will provide comments on the protocol. 
 
Overall, I believe that the appropriate process for handling this document
is not to bring it to IETF last call as an individual submission, but rather
to charter a work item within an IETF WG.  
 
There are two current EAP method drafts that are based on zero-knowledge
algorithms:
1. http://tools.ietf.org/html/draft-harkins-emu-eap-pwd (this document)
2. http://tools.ietf.org/html/draft-sheffer-emu-eap-eke
 
Previously there was also an EAP method submission utilizing SRP:
3. http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03
 
All three of these documents were slated for inclusion on the IETF standards
track. 
 
Given the number of EAP method RFCs that have already been published, I do
not believe that it serves the Internet community for the IETF to publish
multiple EAP method specifications of a similar genre on the Standards
Track, while bypassing the WG process.  
 
If the standardization of zero-knowledge algorithms is an important area of
work for the IETF (and I believe this to be true), then work in this area
should be chartered as a working group work item, with the goal to select a
single method for standardization.  Prior to the EMU WG re-charter, Dan
Harkins made an argument for chartering of work in this area.  His arguments
were sound then, and they are (even more) sound today.  However, Dan did not
succeed in getting the work added to the EMU WG charter.  It is time for the
IESG to re-consider its decision to delay standardization of zero knowledge
algorithms, which was made in the earlier part of the decade.  If the EMU WG
is not suitable for handling this work, then another security area WG should
be created for the purpose.  

I think that this is a splendid idea.  Of course it's too late to schedule a
BoF in Stockholm, it would have to wait until Hiroshima.  If such an
activity were to be organized, might you be interested in reviving the SRP
work?

 

~ gwz

 

Half a loaf is better than no loafing at all.

  --T-Bone Slim

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

[Mark Nottingham]

FYI:

I'm tracking proposed changes to -06 as a result of Last Call at:
  http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt

with a diff at:
  
http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html

Cheers,

--
Mark Nottingham http://www.mnot.net/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Stockholm airport

[Cary Karp]

Two other things that may be worth noting--

The express train between the city and Arlanda has a special summertime
ticketing deal where 2 adults traveling together can share a single
ticket costing 250 kr.

Also the 24 hour, 72 hour, and 7 day travel passes on the public transit
system are good for the ferries that traffic the downtown waters, and
the "museum" tram
http://www.sparvagssallskapet.se/djurgardslinjen/english.php

>>> 1. Taxi.
>>> Expect to pay no more than SEK 500. Reputable taxi companies have
>>> fixed prices around that. I prefer Taxi Stockholm, Taxi Kurir, and Taxi
>>> 020.
>>>
>>> 2. High-speed direct train Arlanda Express.
>>> Its Stockholm terminus is a mere 3 minutes walk from the conference hotel.
>>> Return tickets at around SEK 460:-
>>> https://www.arlandaexpress.com:443/default.aspx?page=3&;
>>>
>>> 3. Airport coach service Flygbussarna.
>>> A five minute walk from the hotel when in Stockholm.
>>> Return ticket SEK 199:-. Tickets on the buses only payable by credit card.
>>> http://www.flygbussarna.se/Default.aspx?lang=EN
>>>
>>> 4. Public transport. From Arlanda to town:
>>>
>>> You CAN'T buy a ticket on the bus!
>>>
>>> a. Get a ticket. Locate Arlanda Visitor Center in Terminal 5 and tell them
>>> you want a SL ticket to Stockholm, via bus 583 etc. I think they sell a
>>> strip of 16 tokens for SEK 180:- which is good for 4 single trips to or
>>> from the airport. They  sell the 7 days card too, which is a very wise
>>> choice if you expect to use the public transport at all during the week.
>>> Price for the card is SEK 260:-
>>> Also ask where the 583 stops. As a courtesy to the more expensive forms of
>>> transfer, the 583 is hidden so as to not appeal to much ;-)
>>>
>>> b. Locate the
>>> bus stop for bus no 583, destination "Märsta Station". 583x might work
>>> too, but make sure that the destination is Märsta.
>>>
>>> c. Get on, and get off
>>> after some 20 minutes at the Märsta Station end stop. (You can't go too
>>> far unless you are on the wrong direction.)
>>>
>>> d. At the station, get on the
>>> commuter train for Stockholm (direction Södertälje). The trains and buses
>>> match in time, so you have something like 5-8 minutes to get off the bus
>>> and on the train.  Plenty, it is just a 100 metre walk. e. Get off at
>>> Stockholm Central, just after station Karlberg. The
>>> hotel is just 7 minutes away by foot. Get out of the platform  in the
>>> north end, at the rear of the train. Much easier.
>>>
>>> On tickets: They are stamped by the driver in the beginning of each
>>> trip (on buses) or by platform access people in booths before getting on
>>> the platform. Make sure to keep the ticket. Controls happen. Also, the
>>> ticket is vaild one hour from stamping time, and will be amendable by new
>>> stamping when changing to a new means of transport within the hour. The
>>> one-week card is easier, magnetic stripe or RFID.

>> For more information about public transportation in Stockholm, please
>> visit . There you'll
>> find information in English on prices, tickets and a journey planner. More
>> languages are available at .

> Moreover, for those of you who decide to stay in Stockholm after (or
> arrive before) the meeting I would recommend you to get the Stockholm
> Card
> http://beta.stockholmtown.com/en/Information/Buy--Order/The-Stockholm-card/,
> which gives you free admission to a lot of museums and attractions on
> top of free travel by public transportation and bonus offers with
> discounts on sightseeing tours among other things. You may choose from
> three different categories: 24 hours, 48 hours or 72 hours


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf