> "Christian" == Christian Huitema writes:
Christian> On Tuesday, July 14, 2015 9:01 AM, Kathleen Moriarty wrote:
>> Is there interest in reviewing this draft? Sam pointed out the
>> importance of moving this work forward, it would be helpful to
>> have volunteers to review t
> "Kathleen" == Kathleen Moriarty writes:
Kathleen>I meant to send the link to Dan's draft:
Kathleen> https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-01
Kathleen> Long week...
I have briefly reviewed the goals behind this proposal and a sketch of
the details but have
> "Alan" == Alan DeKok writes:
Alan> The idea was to allow *provisioning* of the
Alan> Response/Identity. Automatically deriving it from the
Alan> method-specific "user identity" is just as bad as
Alan> automatically using a 3GPP identity.
Unfortunately in contexts like A
Hi.
My life has been hectic, and I completely dropped the ball on this!
Thanks for doing this.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Hi.
At the most recent ABFAB meeting I brought up the idea of adding
ephemeral keying to ABFAB.
This would provide the following:
* Protect the EAP conversation between the peer and NAS (initiator and
acceptor in GSS terms)
* Provide a key to protect ABFAB negotiations
* Prevent the EAP serv
>>>>> "Sam" == Sam Hartman writes:
Sam> We noticed a situation where our AAA server was generating a
Sam> channel binding response that was rejected by our supplicant
Sam> code.
Sam> We looked into things and determined that the server w
We noticed a situation where our AAA server was generating a channel
binding response that was rejected by our supplicant code.
We looked into things and determined that the server was generating a
single octet failure response (code 3) and was including no attributes.
After re-reading section 5
>>>>> "Martin" == Martin Stiemerling writes:
Martin> Sam,
Martin> On 08/24/2013 03:41 PM, Sam Hartman wrote:
>>>>>>> "Martin" == Martin Stiemerling
>>>>>>> writes:
>>
Mart
>>>>> "Martin" == Martin Stiemerling writes:
Martin> Hi Sam,
Martin> On 08/14/2013 10:16 PM, Sam Hartman wrote:
>>>>>>> "Joseph" == Joseph Salowey (jsalowey)
>>>>>>> writes:
>>
Jose
> "Stefan" == Stefan Winter writes:
I think this is too detailed.
The error codes MAY be used.
Full stop.
Whether you can is a complex policy and implementation discussion best
hidden behind a MAY.
___
Emu mailing list
Emu@ietf.org
https://www.ietf
I wanted to make sure that people in emu are aware that the EAP
applicability statement update for application authentication is in IETF
last call.
--Sam
--- Begin Message ---
The IESG has received a request from the Application Bridging for
Federated Access Beyond web WG (abfab) to consider
OK. Based on your description of how peer and server ID are used, I have
no concerns about 3.4.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
> "Joseph" == Joseph Salowey (jsalowey) writes:
[Joe] THis is a reasonable request. We'll need to make sure there is no
ambiguity in the use of the empty message. Should this be covered in RFC
6677?
RFC 6677 doesn't talk about how you decide you're going to do channel
binding. I had m
> "Alan" == Alan DeKok writes:
Alan> Alan DeKok wrote:
>> This is a WG last call on the draft-ietf-emu-eap-tunnel-method
>> document. Please post reviews, comments, feedback, etc. to this
>> list.
>>
>> The WG last call will last two weeks, until February 26.
>>
> "Jim" == Jim Schaad writes:
>> There doesn't seem to be a way for a server to request channel
>> binding. If that's true we should probably add the following:
>> Since a server cannot indicate a desire for channel binding,
>> clients that
Jim> have
>> channel binding
There's an outstanding comment asking for a change to the ascii art.
Besides that I believe we've addressed the comments and generally
improved the draft.
I think it's ready for last call.
I do suspect we'll collect some more comments and have some
clarifications after last call, but I suspect la
Hi. I've included a survey of tunnel methods that have made it to RFC
and TEAP. It's quite possible that people want to cover more tunnel
methods in the summary (LEAP, PEAP, EAP-TTLS v1).
People who want to supply text are welcome to do so.
After looking at it, I don't feel comfortable volunteer
First, the document has been improved a lot in its clarity since the
last time I read it. I'd really like to thank the editors, Jim and
everyone else who gave comments for some excellent work.
TEAP is by far the best EAP method I've ever reviewed, and I think
security of EAP conversations would
So, the current crypto binding draft has empty sections for a survey of
tunnel methods and a survey of inner methods.
Does anyone have an idea what was going to go in those sections? I'm
guessing I put those section headers there, but I cannot remember what I
was going to survey for.
If there's
> "Jim" == Jim Schaad writes:
Jim> As was pointed out to me, the subject message on the message
Jim> had the wrong draft name (even if the version number was
Jim> right).
Thanks for the review.
I've addressed all the comments except:
1) I'm asking a co-author to help with your r
>>>>> "Alper" == Alper Yegin writes:
Alper> On Oct 19, 2012, at 5:08 PM, Sam Hartman wrote:
>>>>>> "Alper" == Alper Yegin writes:
>>
Alper> Hi Sam, Please also share this discussion with EAP WG and EMU
Al
I'd appreciate it if someone could review the diagrams in section 5.3 of
http://www.rfc-editor.org/authors/rfc6677.txt
and confirm that those diagrams match the text.
Once I get a confirmation there I think we're ready to approve the
channel bindings RFC.
___
> "Jim" == Jim Schaad writes:
Jim> Sam et al,
Jim> 1. In section 1 after the Classic Tunnel Attack figure, I believe
there are
Jim> three methods listed as possible mitigation strategies, however I don't
Jim> understand how the second one - a sufficiently strong inner method
> "Jim" == Jim Schaad writes:
Before the outer MSK has been computed, yes.
Before the inner MSK (the one you need to attack crypto binding) has
been computed no.
Also, note that the RADIUS server only knows about the inner method, so
it will transport the inner MSK as soon as it believes the
> "Hao" == Hao Zhou writes:
Hao> Sam:
Hao> This is a well thought and well written draft, it covers a lot of
background
Hao> and aspect of the attacks and mitigations. However, I have few
comments:
Thanks!
You listed a set of drawbacks to EMSK-based crypto binding.
Hao> A.
> "zhou" == zhou sujing writes:
zhou> To my understanding, right prior to finishing tunnel establishement,
EAP peer
zhou> and EAP Server(print server in the server insertion attack case)
should have
zhou> exchanged channel binding with integrity protection by key only known
to
> "Joe" == Joe Salowey writes:
Joe> So, is your concern with using only MSK crypto binding with an inner
EAP authentication method used to authenticate an unauthenticated/poorly
authenticated tunnel or is it more specific to the nea-pt-eap method?
Joe> For the first concern it may
I don't believe that existing crypto binding is adequate for NEA's needs
as discussed in draft-hartman-emu-mutual-crypto-binding.
Unfortunately, though, I'm not sure that tls-unique helps enough here. If
the outer method actually does provide server authentication as
deployed, then tls-unique is
> "zhou" == zhou sujing writes:
zhou> 3. also in rfc 5247
zhou>TEKs are output from EAP methods and were designed to
zhou> secure the channel, couldn't they be used in channel binding
zhou> or crypto binding?
TEKs can and typically will be used for channel binding. C
> "Stephen" == Stephen Hanna writes:
Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily
Stephen> address almost all of the comments in my April 13, 2012
Stephen> secdir review. I do have one remaining substantive comment
Stephen> on this latest draft and two n
> "zhou" == zhou sujing writes:
I don't really understand how that would be possible. If a fresh MSK
and EMSK are generated per session, which we'd expect in a good EAP
method, they need to be generated from something. So, I'd need to
better understand what was happening if we had an EAP
> "zhou" == zhou sujing writes:
zhou> If there is another key available, it will be great, EMSK? It
zhou> has been suggested for cryptographic binding.
I'm expecting that most EAP methods will use a key internal to their
heirarchy above both the MSK and EMSK. For example I'd expect
> "zhou" == zhou sujing writes:
zhou> Hi all
zhou> In section 9.1 One attractive implementation strategy for
zhou> channel binding is to add channel binding support to a tunnel
zhou> method which can tunnel an inner EAP authentication. was
zhou> expected to introducing
This version includes a large number of changes mostly to respond to the
secdir review.
I'm not entirely sure that Stephen Hanna will be happy with the changes
in section 9, but I'd like to start there and see where we are. I think
it's a good idea for WG members to review these changes.
__
I have no problemdocumenting why we do not do so as an example of privacy in
sec cons
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Alan DeKok wrote:
Sam Hartman wrote:
> I'd like to take a step back and ask why you'd ever want to channel-bind
> user-n
Steve Hanna did a secdir review of draft-ietf-emu-chbind. One of the
issues he raised is a privacy concern with section 8. He points out
that we recommend using the user-name attribute in channel binding. The
concern is that if a server checks user-name in i2 against user-name in
i1, then a NA
> "Jim" == Jim Schaad writes:
Jim> 3. 3.2.3 or 3.2.2 - If you had a non EAP method, and it
Jim> derived a key (just like a good EAP method). Is there any
Jim> reason why you could not do the cryptographic binding? Other
Jim> than it is not currently defined in one of the c
1) TEAP extends TLS RFC 5077
In section 2, TEAP discusses using phase 2 TLVs to include a TLS session
ticket and an associated secret key.
RFc 5077 only permits session tickets to be sent using the session
ticket message. I believe that this is an extension to TLS that would
need to go through
Let's meet Monday at lunch.
We should try and get a count of interested people.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Dear Hao:
I was pleased to hear your analysis of areas where mutual crypto binding
may be tricky to deploy because I would like to accurately describe this
problem space. I believe the draft covers most of the points you raise
but I will definitely incorporate your feedback.
I was a bit frustrate
> "Pascal" == Pascal Urien writes:
Pascal> Hi Sam EMU meansEAP Method Update.
Hi. Thanks for the clarification. It turns out I'm reasonably familiar
with the history of the EMU and EAP working groups.
I remain confused. If you are ready to publish your draft, why do you
need to present
> "Pascal" == Pascal Urien writes:
Pascal> The goal of the presentation at the IETF 83 in Paris is to
Pascal> push this draft as an Informational RFC.
Hi. I'm glad you want to publish this work as an RFC because I believe
it's valuable and I'd like to see it an archival form.
I'm su
Hi.
I'm confused.
I'd like to understand why you'd like to present this draft?
What response are you hoping for from the EMU working group?
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Hi.
I'm posting a new version of the channel bindings draft in response to
AD review comments.
I've been requested to develop security considerations text in response
to attacks I wrote about on the list.
Here's the text I'm including in the new draft.
Comments are welcome.
I don't know if Sean w
Folks, I'd like to draw your attention to a draft we've put together
describing the crypto binding interaction with channel binding and other
peer-focused EAP services that I posted back in January. Please see
draft-hartman-emu-mutual-crypto-bind-00.txt.
there are a few rough edges. A couple of
> "Jim" == Jim Schaad writes:
Jim> There is one other item that is also worrying me about this.
Jim> In doing the check of certificates, one should be doing
Jim> revocation checking. However if one is trying to get network
Jim> access, one cannot independently download the re
Hi.
I'm writing up a draft on mutual crypto binding.
As such, I happened to glance at section 7.6 on server certificate
validation.
The advice there is entirely inadequate for interoperable
implementation and violates the tunnel method requirements:
1) . There's a SHOULD check the server name,
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
>>>>> "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
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
>>>>> "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
> "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
> "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
>>>>> "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
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
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
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
> "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
> "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
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
> "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
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:
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
>>>>> "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
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
> "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
>>>>> "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,
Yoshihiro> (2011/10/20 21:48), Sam Hartman wrote:
>>>>>>> "Yoshihiro" == Yoshihiro Ohba
>>>>>>> writes:
>>
Yos
> "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, 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
> "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
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
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
>>>>> "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
>>>>> "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
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
> "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
> "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
[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,
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
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
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
> "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" == 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> 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
> "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
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
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
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.
___
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
> "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
> "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> 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
> "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),
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/
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 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
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
> "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
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
1 - 100 of 147 matches
Mail list logo
