On Jul 22, 2013, at 8:20 AM, Stefan Winter stefan.win...@restena.lu wrote:
Hello,
I didn't follow TEAP's creation process in enough detail, so may have
missed some information. Apologies if what I write below is noise.
I have two questions about TEAP Version 1 which I don't find
Yes, this document is the main thing on the agenda.
On Jul 25, 2013, at 6:26 AM, Josh Howlett josh.howl...@ja.net
wrote:
Section 3.2 of draft-wierenga-ietf-eduroam describes the issues presented
by EAP's spartan support for error condition handling. Although these are
described in the
with network
access usage.
Thanks,
--David
-Original Message-
From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.comhttp://cisco.com]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Black, David
Cc: stefan.win...@restena.lumailto:stefan.win...@restena.lu; General Area
Review Team; ab
On Jun 18, 2013, at 7:18 AM, Sam Hartman hartm...@painless-security.com
wrote:
Black, == Black, David david.bl...@emc.com writes:
Black, The next to last paragraph on p.3 begins with this sentence:
Black,For these reasons, channel binding MUST be implemented by
Black,
I think we could state this a bit better as something like:
In environments where EAP is used for applications authentication and
network
access authentication all EAP servers MUST understand channel bindings and
require that application bindings MUST be present in application
On Jun 18, 2013, at 11:39 AM, Sam Hartman hartm...@painless-security.com
wrote:
Joe, eap-lower-layer is not required for application authentication if
there's some other attribute that's specific to the lower layer. For
example Moonshot sends gss-acceptor-service-name but does not currently
The deadline for providing additional information was yesterday.
The results very clearly show that the course of action preferred by the
community is publishing the document without making further changes to
the details concerning the SCSV.
Cheers,
Joe
TLS Working group co-chair
According to
I disagree that the last call is premature. I realize that not everyone
is happy with all aspects of the current document but a clear majority
of people on the TLS list have voiced their support for it. I do not
see any consensus that the existing approach is flawed, nor do I see
evidence of an
-Original Message-
From: Simon Josefsson [mailto:si...@josefsson.org]
Sent: Tuesday, September 29, 2009 10:20 PM
To: Joseph Salowey (jsalowey)
Cc: Michael D'Errico; martin@sap.com; ietf@ietf.org; t...@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis
It seems that this is really up to the application. Both server names
are authenticated under the same session. It seems an application
server may require them to be the same or allow them to be different.
-Original Message-
From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org]
Comments on draft-harkins-emu-eap-pwd-04
1. Prime Modulus groups
In 2.1.1 the document says if the order is unspecified to use (p-1)/2
and in 2.6.4.2 it says to use (p-1). It's not really clear which you
mean to use. In general I don't think you can make specific claims
about the order of the
I also think this should be done in a working group.
Joe
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Bernard Aboba
Sent: Wednesday, July 22, 2009 5:37 PM
To: ietf@ietf.org
Subject: Re: Last Call: draft-harkins-emu-eap-pwd (EAP
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
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
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
Hi Jari,
-Original Message-
From: Jari Arkko [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 2:24 AM
To: Joseph Salowey (jsalowey)
Cc: Pasi Eronen; ietf@ietf.org; [EMAIL PROTECTED]
Subject: Re: Last Call: draft-arkko-eap-aka-kdf
(ImprovedExtensible
Hi Jari,
This discussion has prompted me to look at the spec again. Is there a
need to fall back to the AKA derivation? It seems that the AAA
providing AKA or AKA' support would know what is supported by the
infrastructure. Having the fallback to AKA is confusing. If you chose
the alternate
Hi Vidya,
I think this is an excellent start. I'll put some applicability and
security considerations text together for the document for discussion on
the list.
Cheers,
Joe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Narayanan, Vidya
Sent:
Thanks for your quick response, comments inline:
-Original Message-
From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 06, 2008 1:03 AM
To: Joseph Salowey (jsalowey)
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: [HOKEY] Last Call: draft-ietf-hokey
There is nothing in the document that says you must index keys only by
key id. I don't really understand the problem here, there is other
context associated with a key besides a name that can be used for
indexing. The key name provides a fixed length unique identifier for
the key. EAP
-Original Message-
From: Dan Harkins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 05, 2008 12:23 PM
To: Joseph Salowey (jsalowey)
Cc: Dan Harkins; ietf@ietf.org; [EMAIL PROTECTED]
Subject: RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP
Extensions for EAP Re
In reading this draft (-09 version) I came up with a few questions and
comments:
Section 3 -
Section 3 is a bit confusing it seems that much of the text is section
3.1 (detailed description of exchanges) should go into section 3.0
because it seems that much of the process should be the same for
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like
-Original Message-
From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 07, 2007 9:21 PM
To: Joseph Salowey (jsalowey)
Cc: iesg@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Isidor Kouvelas (kouvelas); Tony Speakman (speakman);
[EMAIL PROTECTED]; [EMAIL
snip
* EAP lower layer and GEE - Bernard's review pointed out
that the EAP
lower layer transport requirements are not discussed in the
GEE draft.
GEE is not an EAP lower layer. GEE is a protocol that the EAP lower
layer can use to allow multiple parallel authentications.
As I
-Original Message-
From: Russ Housley [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 10:48 AM
To: Joseph Salowey (jsalowey); ietf@ietf.org
Subject: RE: Last Call: 'Guidance for AAA Key Management' to
BCP (draft-housley-aaa-key-mgmt)
Joe:
I'm not really clear
Thanks Bernard,
Comments inline.
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 2:00 PM
To: ietf@ietf.org
Cc: Joseph Salowey (jsalowey)
Subject: Re: Last Call: 'Guidance for AAA Key management' to
BCP (draft-housley-aaa-key
Hi Russ and Bernard,
I'm not really clear on the purpose of the document. What does it apply
to? Does it require changes to existing AAA protocols? Does it add new
requirements to EAP methods that are not in RFC3748? It would probably
be good to reference 3748 when it applies to a requirement
28 matches
Mail list logo
