Dear Alan DeKok,
I'm Shin.
I submitted the below I-D (00) and want to introduce our work.
Could you please let me know if it is possible for me to present
our work in emu WG?
Filename:draft-shin-augmented-pake
Revision:00
Title: Most Efficient Augmented Password-Only A
> 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 curre
Hi Yaron,
The existing text is just about restricting the mandatory to implement
cipher suites. Are you OK with the text?
Thanks,
Joe
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Yaron Sheffer
> Sent: Wednesday, March 03, 2010 11:05
Hi Joe,
Yes, I am OK with the text.
Thanks,
Yaron
> -Original Message-
> From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
> Sent: Thursday, March 04, 2010 17:12
> To: Yaron Sheffer; Alan DeKok
> Cc: emu@ietf.org
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-r
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
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
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
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 sa
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:dhark...@lounge.org]
> Sent:
