> "Bernard" == Bernard Aboba <[EMAIL PROTECTED]> writes:
>> But could not EAP-TLS be modified/updated to also allow "pure"
>> TLS-PSK, without requiring use of server certificates? AFAICS
>> this would still be TLS, not "TLS-derived" or "based on TLS".
Bernard> RFC 2716 requir
> "Salowey," == Salowey, Joe <[EMAIL PROTECTED]> writes:
Salowey,> The security requirements in 4017 are not comprehensive,
Salowey,> however I don't think the security requirements for PSK
Salowey,> need to be comprehensive. I would rather not open up
Salowey,> the list of re
In general, it seems that the TLS community has been recommending a
second authentication if you have data you need to exchange that is
confidential and would normally be in the first authentication. See
draft-housley-tls-authz-extns for an example of the use of this
method.
Clearly using this wi
> "Hannes" == Hannes Tschofenig <[EMAIL PROTECTED]> writes:
Hannes> Hi all, before we spend more time considering EAP
Hannes> tunneling methods like PEAP and TTLS I would like to hear
Hannes> the opinion of our ADs on this subject. So far, the
Hannes> working assumption was th
> "Tschofenig," == Tschofenig, Hannes <[EMAIL PROTECTED]> writes:
Tschofenig,> Hi Sam,
>> > "Hannes" == Hannes Tschofenig <[EMAIL PROTECTED]>
>> writes:
>>
Hannes> Hi all, before we spend more time considering EAP
Hannes> tunneling methods like PEAP and TTLS I woul
Hi.
For the last couple of years, we've been believing that EAP and GSS
used the term channel bindings inconsistently. For those of us
dealing with both, it's been a bit annoying.
I've been thinking about EAP a lot lately. and have come to the
conclusion that actually the terms are used consi
> "Charles" == Charles Clancy <[EMAIL PROTECTED]> writes:
>>> to be an L2 identity. It can be any identity that's
>>> meaningful to the parties involved, and can serve as the basis
>>> for making authorization decisions.
>> As long as it's cryptographically bound to the L2 ch
> "Nicolas" == Nicolas Williams <[EMAIL PROTECTED]> writes:
Nicolas> Also, I think my draft's definition of "end-point channel
Nicolas> bidning" needs to be tightened just a bit: not only must
Nicolas> the end-point IDs be cryptographically bound into the
Nicolas> channel, it m
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
>> I think that having a single abstraction that can describe
>> what went by multiple names in different areas can be very
>> useful because it facilitates cross-area communication. And
>> missing an opportun
As a matter of process, if EMU is going to satisfy its charter item
regarding passwords, it will need to refer to a standards-track EAP
type of some kind. The existing process for getting EAP methods
published as RFCs does not result in standards track RFCs.
So, if EMU is going to base its work o
> "Alan" == Alan DeKok <[EMAIL PROTECTED]> writes:
Alan> Hao Zhou (hzhou) wrote:
>> I think publishing a "widely" deployed EAP method is orthogonal
>> to publishing a new method meeting EMU charter. I agree
>> publishing the existing method as deployed is something needs
>>
> "Lakshminath" == Lakshminath Dondeti <[EMAIL PROTECTED]> writes:
Lakshminath> I would like to see the crypto-binding stuff (not
Lakshminath> compound binding -- as others have noted, we don't
Lakshminath> have consensus on that topic) and extensibility (how
Lakshminath> to ad
> "Alan" == Alan DeKok <[EMAIL PROTECTED]> writes:
Alan> My opinion is that normalization belongs at the edge,
Alan> which generally also has information about the language and
Alan> locale. Once normalization is performed, the password can
Alan> be sent over the wire *witho
that the client should
>> do (often none) and set interoperability goals.
Alan> The whole composed / decomposed thing is a nightmare for
Alan> passwords.
And one the emu working group needs to deal with.
Sam hartman
Security Area Director
_
>>>>> "Alan" == Alan DeKok <[EMAIL PROTECTED]> writes:
Alan> Sam Hartman wrote: The whole composed / decomposed thing is
Alan> a nightmare for passwords.
>> And one the emu working group needs to deal with.
Alan> RFC 3629 says
servers. Once I'm
convinced it is possible to add in the future, I will be OK on the
channel bindings issue.
does this seem reasonable?
Sam Hartman
Security Area Director
___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
> "Yoshihiro" == Yoshihiro Ohba <[EMAIL PROTECTED]> writes:
Yoshihiro> It is possible to add, at later stage, an interopelable
Yoshihiro> channel bindings mechanism that can work with old
Yoshihiro> clients and servers, by using EAP-EXT method with
Yoshihiro> running any EAP au
> "Joseph" == Joseph Salowey (jsalowey) <[EMAIL PROTECTED]> writes:
Joseph> 2) Should EAP channel bindings be sent from the peer to
Joseph> server, server to peer, or both.
I hope you can avoid needing to answer this question as it could be a
bit tricky.
___
s-security.com/blog/2010/02/12/moonshot1
You can find the feasibility analysis at
http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf
Thanks,
Sam Hartman
Painless Security
___
Emu mailing list
Emu@ietf.or
This is one of the documents for the bar bof on federated authentication
I sent mail about a couple of weeks ago.
Discussion currently on moonshot-commun...@jiscmail.ac.uk.
--- Begin Message ---
A new version of I-D, draft-howlett-eap-gss-00.txt has been successfuly
submitted by Sam Hartman
r the announcement of the proposal see
http://www.ietf.org/mail-archive/web/emu/current/msg01363.html
and for our mailing list see
http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY
Thanks for your interest,
Sam Hartman
Painless Security, LLC
___
Folks, I'm looking forward to seeing some of you at the bar bof on
federated authentication for non-web applications this evening at 9 PM
in the Manhattan room. Please see
http://www.painless-security.com/blog/2010/03/25/moonshot3 for a
detailed reading list and remote participation instructions.
I'm told there were around 30 people in the room. That seemed like a
good turn out for Thursday at 9 PM.
Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication for non-web applications.
Two so
> "Alper" == Alper Yegin writes:
Alper> Was this discussed? Is there a proposal to expand the
Alper> applicability statement of EAP now? Where do we draw the new
Alper> line now?
I've certainly been thinking about it.
Quoting http://www.painless-security.com/blog/2010/02/12/moo
> "Alper" == Alper Yegin writes:
>> authentication. The first is that EAP >only authenticates the
>> home realm; it does not authenticate what >service youùre
>> going to. So you might try to connect to your >e-mail and end up
>> giving something access to your stored files an
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that
meeting, I sat down with Glen to understand his concerns with the
document. I'd like to write up my notes on that meeting and to discuss
what I think the critical next steps are for the document.
I presented two motivating
I will definitely have a revision for IETF 78. I may not have
everything I'd like to have done ready for that revision.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Hi. I'd like to announce that there will be a BOF on federated
authentication beyond the web at IETF 78. we'd like to form a working
group to standardize protocols for federated access to applications that
are not browser based. Targets include think client applications and
some machine-to-mach
During the discussion between Glen and Alan there was a lot of
discussion about transitive trust.
Alan gave a case where a user might be wanting to choose between two
vendors, X and Y. They charge different prices. If they are directly
connected to the user's home AAA realm, then the home AAA re
Glen asked me to explain my tunnel related comments more.
It would be desirable to reduce the number of methods we need to add
channel binding to. For example if eap-ttls supports channel binding [1]
and I'm running some other method inside it, then I may not care whether
that method supports ch
is introduced.
Glen> Sam Hartman [mailto://hartmans-i...@mit.edu] writes:
>> Consider a corporation that has an internal network and that also
>> has agreements with WIFI hotspots to provide its employees
>> connectivity. Policy requires that people use a
> "Glen" == Glen Zorn writes:
Glen> Or we could use the more direct & much simpler approach of
Glen> allowing the client to authenticate the network to which it is
Glen> attached & use that data to decide by itself. This can be
Glen> done today using EAP-TTLS.
How?
I'd appr
> "Glen" == Glen Zorn writes:
the corporate network example from my first message as
>> a case in point. The corporation has two levels of trust:
>> internal and everyone else. Internal entities may claim to be
>> corporate access points. People who are part of "everyone else,"
> "Glen" == Glen Zorn writes:
Glen> If certificate-based TLS authentication is used & the TTLS
Glen> server is located in the visited network (something that the
Glen> client can check by matching the identity advertised with a
Glen> name in the cert), the task is accomplished
> "Dan" == Dan Harkins writes:
Dan> Hi Alan,
Dan> On Thu, June 24, 2010 5:20 am, Alan DeKok wrote:
>> Glen Zorn wrote:
>> Alan DeKok [mailto:al...@deployingradius.com] writes:
The requirement to keep authentication credentials private,
which is one of the reas
> "Bernard" == Bernard Aboba writes:
> environment that the client is gaining access to. the EAP
> server's job
> is to verify that the channel binding is consistent and if
> not, reject
> the access request."
Bernard> [BA] The server's job is not only to verify that the
Bernar
Folks, at IETF 77 I volunteered to edit the channel bindings document
and have published a new version for discussion at IETF 78.
I'd appreciate comments on whether the changes I made to the problem
statement sections include clarity. I'd also appreciate comments on
whether the tradeoffs in the
> "Alan" == Alan DeKok writes:
Alan> Hoeper Katrin-QWKN37 wrote:
>> I did not attend the last EMU WG meeting in person, but as a
>> remote participant it appeared to me that there was a general
>> consensus that the channel binding draft
>> (draft-ietf-emu-chbind-05) shoul
So, this paper makes it clear that I don't understand some of this stuff
as well as I thought I did. No surprise there; it's complicated and
this has not been my primary area of focus. so let's see if I can be
educated.
In the part of the world I'm familiar with, we address this problem by
auth
> "Hoeper" == Hoeper Katrin-QWKN37 writes:
Hoeper> I agree. That's why I was thinking that adding a reference
Hoeper> that makes implementers aware of this problem would be a
Hoeper> good idea. Then they can make an educated decision about
Hoeper> whether they want to implemen
> "Joe" == Joe Salowey writes:
Joe> The basic reason for this is that EAP methods have a well
Joe> defined mechanism to output key material. There hasn't been a
Joe> mechanism to import data into a method, channel bindings may
Joe> change this.
OK, but I'm not sure this quite
>>>>> "Alan" == Alan DeKok writes:
Alan> Sam Hartman wrote:
>> * The client wants assurance that it's talking to a consistent
>> server so that you only end up having to authenticate the server
>> at one level.
Alan>
> "Joe" == Joe Salowey writes:
As I discussed with the chairs, I'm making an update, but it's more of
an update to address specific detailed comments than to really move the
document forward. There have been some issues in my availability, which
I believe are very close to being resolved. T
Hannes, at the EMU meeting we were discussing whether there are any
attributes we're likely to want to bind to in EAP channel binding that
are in the diameter rather than RADIUS namespace.
I asked for your thoughts and you said you'd have to look into it.
Any chance you could get input (with ap
> "jouni" == jouni korhonen writes:
jouni> Hi,
jouni> As far as I remember there are no specific AVPs for channel
jouni> binding purposes defined for any Diameter application
jouni> documented in IETF.
That's not really the interesting question.
The interesting question is w
> "Dan" == Dan Harkins writes:
Dan> Hi Sam,
Dan> I know you have expressed your desire to use an existing
Dan> registry to identify channel binding information, I just don't
Dan> recall hearing you say why it's a good idea. Could you explain
Dan> the benefits (once mo
>>>>> "Alan" == Alan DeKok writes:
Alan> Sam Hartman wrote:
>> So, I think we're better off with an existing registry provided
>> that we can get things we need registered in it. I think it's not
>> a huge deal to go do
At the last IETF, Glen proposed that rather than using diameter's
namespace for channel binding AVPs we use the RADIUS namespace. There
were two aspects to this concern. One is that diameter has a larger
length value for attributes. If we're routinely exceeding 253-octets for
values that are part
> "Alan" == Alan DeKok writes:
>> 2) Have multiple namespaces for attributes we support. This may
>> remove a lot of the overhead savings for RADIUS over Diameter; in
>> the obvious implementation I'd expect we would waste a byte per
>> AVP.
Alan> I'm not sure what you
The major difference in this version is that I've thrown together a
candidate protocol based on the discussions of the last few days.
I think this should give us something concrete to discuss.
While I think the text includes the necessary information, there are
three places where packet diagrams
I considered retaining namespace-specific packing. my concern is that
in the channel binding response you want to remove values. This ends up
being a bit namespace specific because of VSAs but seems to argue for
the channel binding logic ending up getting stuck with a fair bit of
namespace specif
I'd very much like to discuss the changes to the channel binding draft.
The highest level item is whether we're going in the right direction.
I'd also like to come to closure on Alan's comment about whether we want
each AVP split out or whether we want to reuse more of the
RADIUS/whatever encoding
I just want to confirm I haven't missed mail.
It's my understanding that the call for proposals for tunnel methods
closes March 7 and that so far we've seen no submissions.
Is that correct?
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/
> "Glen" == Glen Zorn writes:
Glen> On 4/16/2011 2:21 AM, Stephen Hanna wrote:
>> I agree with Katrin's count for the email poll. When combined
>> with the count from the meeting in Prague (since Alan asked for
>> only folks who didn't attend the EMU WG meeting in Prague),
> "Alan" == Alan DeKok writes:
Alan> Stefan Winter wrote:
>> Attribute parsing should be easier with this option 1 - Length
>> can always serve as a pointer to the next attribute, with
>> explicit namespace ID. With option 2, attribute delimiters are
>> only within NS-Spec
> "Alan" == Alan DeKok writes:
Alan> There is plenty of BSD-licensed code available for packing
Alan> and unpacking RADIUS attributes. There should be little cost
Alan> to re-using that, and a larger cost in writing a new attribute
Alan> packer.
Assuming RADIUS is basical
> "Alan" == Alan DeKok writes:
Alan> Glen Zorn wrote:
>> There seem to be two issues here: renaming the draft & allocating
>> a new EAP type. For which one are opinions being solicited?
Alan> Allocating a new EAP type.
My opinion is that we have two options:
1) Allocate
I'd like to confirm my understanding.
The current text proposes the use of eap type code 43.
I'd like to confirm that code is in use both by implementations of
eap-fast v1 and v2.
Does the current text mandate support for eap-fast v1 as well as v2?
Is it expected that most implementations wil
Based on the answers to my questions, I strongly support allocation of a
new EAP type code . I think using the existing type code will
significantly disadvantage implementations that want to implement the
IETF spec but not eap-fast v1.
I believe that is highly undesirable.
___
Over the past couple of days I've been organizing proposed edits for the
channel binding document.
First, I could really use some help producing some ascii art diagrams. I
think I have non-ascii-art diagrams for the packets involved; is anyone
willing to step forward and help with this?
Secondl
I'm not actually sure channel bindisgs will need time this round. I
think I've done exactly what I said I'd do on the list.
I think one get the diagrams and a review or lack of review on the
802.11 information, we should be ready for last call.
___
Emu
> "Joe" == Joe Salowey writes:
Joe> (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) - this
Joe> is an draft attribute designed to indicate the EAP lower layer.
Joe> It contains several values to cover many of the EAP lower
Joe> layers. IT does cover IKEv2 and PANA. I
> "Dan" == Dan Harkins writes:
Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method.
I support all of dan's changes regarding unauthenticated server mode
with the exception of the quoted text above. I do not generally support
a down-reference to an informational document in a c
>>>>> "Dan" == Dan Harkins writes:
Dan> On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote:
>>>>>>> "Dan" == Dan Harkins writes:
>>
Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method.
>>
> "Dan" == Dan Harkins writes:
Dan> In fact, if you have the ability to to provision 128-bit (or
Dan> greater) blobs in disparate places then you have the ability to
Dan> provision a certificate or something that makes EAP-GPSK
Dan> pointless. If, on the other hand, you real
Dan:
1) My desire to use GPSK with anonymous server authentication is more or
less unrelated to any other part of this discussion. I want to be able
to do it because I think I might deploy it and I don't want the spec to
forbid a deployment I consider reasonable. There is no security
justificatio
Hi.
I've just submitted a draft that I think is ready for last call.
Changes include:
* Figures, thanks Katrin !
* Text stolen from Bernard's draft for the eap lower layer attribute
* IANA considerations for the eap lower layer attribute
* Removal of the 802.11-specific text per WG discussion i
I'm happy to make changes regarding your comments; a couple of them were
not directly actionable but I can make best guesses. Most of them were
directly actionable and I agree the changes improve the text.
I'd appreciate comments from the groups on whether we start codes at 2
or 1.
My default wil
[EMU copied for EAP input]
Here in ABFAB, we're designing a new EAP lower layer for applications to
use for authentication. We're using the GSS-API (RFC 2743) as our
application integration point.
Currently, our lower layer is kind of chatty. The peer sends a first
message that roughly says "Hi,
> "Yoshihiro" == Yoshihiro Ohba writes:
Yoshihiro> [1] As far as I understand, the method-based channel
Yoshihiro> binding is not applicable to ERP. For completeness of
Yoshihiro> the specification it may be good to add some text to
Yoshihiro> clarify this.
I'd welcome sugge
> "Alan" == Alan DeKok writes:
Alan> For me, echoing a copy of an attribute (value and all) means
Alan> that the server validated the attribute. Echoing nothing
Alan> means that the server doesn't know what to do with the
Alan> attribute. Echoing an attribute with an empty
I think I may have been unclear in what I was proposing. I'm proposing
that the peer send its identity in the first message (*) and that the
server gets to respond with type 4 or greater (a specific EAP method).
I'm proposing dropping the identity request, not the identity response.
(*) There's
>>>>> "Rafa" == Rafa Marin Lopez writes:
Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió:
>> I think I may have been unclear in what I was proposing. I'm
>> proposing that the peer send its identity in the first message
>>>>> "Rafa" == Rafa Marin Lopez writes:
Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió:
>>>>>>> "Rafa" == Rafa Marin Lopez writes:
>>
Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escr
Hi. I've added PANA (pre-authentication).
I wonder about the whole lower layer table.
Why is it important to distinguish PANA with pre-auth from pana without
pre-auth?
Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with
pre-auth?
I'd appreciate it if someone who cared about network
I believe I've addressed all of Alan's comments with the exception of
removing the RADIUS diagram from 5.3.
Thanks Alan for the comments!
--Sam
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
> "Jim" == Jim Schaad writes:
>> > Section 4.2.10 - How can I know if the server does or does not
>> process > the channel binding TLV? This may be part of my policy
>> as a peer > depending on circumstances.
>> >
>> [HZ] Currently, the Channel-binding TLV is an optional TL
> "Yoshihiro" == Yoshihiro Ohba writes:
Yoshihiro> Hi Sam, Since authorization and accounting with the use
Yoshihiro> of the pre-authentication may be different from those
Yoshihiro> with the use of normal authentication, it would be good
Yoshihiro> to differentiate pre-auth a
> "Hao" == Hao Zhou writes:
Hao> Rereading the updated chbind draft, it has already defined the
Hao> mechanism for two way communication and tunnel EAP draft just
Hao> defined a TLV container to carry the Channel binding data
Hao> defined in Section 5.3, so we should be ok. N
>>>>> "Yoshihiro" == Yoshihiro Ohba writes:
Yoshihiro> Hi Sam,
Yoshihiro> (2011/10/20 21:48), Sam Hartman wrote:
>>>>>>> "Yoshihiro" == Yoshihiro Ohba
>>>>>>> writes:
>>
Yos
>>>>> "Glen" == Glen Zorn writes:
Glen> On 10/20/2011 3:09 AM, Sam Hartman wrote:
>>
>
> I believe I've addressed all of Alan's comments with the exception of
>> removing the RADIUS diagram from 5.3.
Glen> Great, so w
> "Yoshihiro" == Yoshihiro Ohba writes:
Yoshihiro> Hi Sam, Please see my comments below.
Yoshihiro> sense. Sending channel bindings in the secure
Yoshihiro> association protocol can work even with ERP [RFC5296] in
Yoshihiro> which previously established EAP key material is us
I'll respond to the question of channel binding support now. I think
the current text permits an EAP method to not send channel binding if it
knows the server fails to support it. If your method can discover that
and optimistically avoid sending channel binding that's fine.
I think we discussed
>>>>> "Dan" == Dan Harkins writes:
Dan> On Thu, October 20, 2011 5:48 am, Sam Hartman wrote:
>> Ultimately the chairs are going to have to decide what the table
>> entries are; I think that's beyond what I can do as an editor.
Dan&g
> "Jim" == Jim Schaad writes:
Jim> I want to make sure that we have distinguished between the two
Jim> statements 1. The server says that I don't support these
Jim> specific attributes
Jim> and 2. The server does not tell me that it
Jim> did or did not do matching of s
Hi.
Here are my notes as editor on where I think things stand:
1) waiting for chairs to confirm that we have WG consensus to address
Alan's comments in the way we did
2) Waiting for the chairs to judge consensus or lead a discussion on the
contents of the EAP lower layers table. We should speci
> "Jim" == Jim Schaad writes:
Responding only to things I can respond to without reading the
document. I''m in the middle of another document.
I'll get to the rest sometime next week.
Jim> * In section 5.1 (para 3) - The following sentence does not
Jim> make sense to me. Message i2 i
So, chairs, can I go forward with Joe's suggestions, include the ERP
text and attempt to resolve Jim's comments if I can manage to find time
before the cutoff?
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
> "Sean" == Sean Turner writes:
Sean> Sam, Is there a reason that the registry values aren't 1-9? I
Sean> know there were other values there originally and they were
Sean> dropped, just curious why they weren't renumbered.
First, sorry for coming so late to the meeting. That was
> "Joe" == Joe Salowey writes:
Joe> I think the following appendices of the channel binding
Joe> document are no longer supported by the rest of the text and
Joe> defined attributes. I think they are out of date and should be
Joe> removed: A.3. Downgrading attacks A.4. Bogu
The chairs asked me to prepare a new version with the following changes:
1) collapse the registrations in the lower layer type registry as
requested by Sean.
2) Add a paragraph to the beginning of Appendix A.
I believe I've made these changes. If folks are happy with these two
minor changes I
Hi, folks, at the chairs request I made a couple of changes
1) Replaced MUST not with MUST NOT in one instance
2) Added a reference to Bernard's radext-wlan draft. There was already
textual reference, but not an xref tag.
While doing that I noticed that there was a missing against in the
sesente
I'd like to thank Margaret Wasserman for coming up with a series of
proposed attacks that lead to the following comments.
In the context of implementing channel binding and a system that takes
advantage of it, I've been focusing on MITM attacks. I'd like to give a
example of the sorts of attacks
>>>>> "Alan" == Alan DeKok writes:
Alan> Sam Hartman wrote:
>> Then, assuming we're using TTLSv1, the client will do crypto
>> binding. Intuitively you'd kind of think that crypto binding
>> would help here; I'll discu
> "Hannes" == Hannes Tschofenig writes:
Hannes> Hi Sam, let us start with the problem description: You claim
Hannes> that EAP peer implementations use PK-based authentication
Hannes> but do not do certificate validation. This obviously
Hannes> introduces attacks (regardless of
> "Joe" == Joe Salowey writes:
Joe> Back when we were looking at the crypto binding problem, a MITM
Joe> in the infrastructure was not part of the threat model. We had
Joe> some discussion of this, but we decided were able to get away
Joe> with just using the MSK and that thi
>>>>> "Alan" == Alan DeKok writes:
Alan> Sam Hartman wrote:
>> RFc 5281 does not provide cryptographic binding.
Alan> Well, then I either misunderstand 5281, or I misunderstand
Alan> what crypto binding is. I thought that crypto bindin
Hi.
EAP has a complex history of success indications over the years.
Some methods have protected success indications; some don't.
Especially as channel bindings are being initially deployed it's going
to be common to want to send channel bindings and possibly fail if they
do not match but not
>>>>> "Sam" == Sam Hartman writes:
Sam> Hi.
Sam> EAP has a complex history of success indications over the
Sam> years. Some methods have protected success indications; some
Sam> don't.
Sam> Especially as channel bindings are be
I think that a number of participants will be familiar with some channel
binding implementation work by IETF 83 and I think it would be valuable
to brienf the WG on lessons learned. At one level, we perhaps don't
care about implementation-specific problems or issues that pop up when
adding channe
1 - 100 of 147 matches
Mail list logo
