Looks good to me -- thanks for accommodating this.
Josh.
On 30/09/2013 00:41, "Joseph Salowey (jsalowey)"
wrote:
>Below is the text for the Error TLV. This should have the error
>messages we discussed. I also move the CSR related error messages to
>warnings.
>
>Cheers,
>
>Joe
>
>4.2.6. Er
Below is the text for the Error TLV. This should have the error messages we
discussed. I also move the CSR related error messages to warnings.
Cheers,
Joe
4.2.6. Error TLV
The Error TLV allows an EAP peer or server to indicate errors to the
other party. A TEAP packet can contain 0
On Sep 9, 2013, at 8:10 AM, Josh Howlett wrote:
>>>
>>> - User account credentials incorrect
>>> - User account credentials change required
>>
>> [Joe] I am concerned that these error messages reveal too much
>> information to an attacker.
>
> I agree there are risks if used inappropriately,
>>
>>- User account credentials incorrect
>> - User account credentials change required
>
>[Joe] I am concerned that these error messages reveal too much
>information to an attacker.
I agree there are risks if used inappropriately, but nonetheless there are
reasonable uses for these (for example,
On Sep 9, 2013, at 1:44 AM, Josh Howlett
wrote:
> Joe,
>
> Thanks for this. This looks good, but I am missing:
>
> - User account credentials incorrect
> - User account credentials change required
[Joe] I am concerned that these error messages reveal too much information to
an attacker.
>
Joe,
Thanks for this. This looks good, but I am missing:
- User account credentials incorrect
- User account credentials change required
And also (using "Inner method" to disambiguate inner method CB from TEAP's
own CB):
- Inner method's channel binding data required but not supplied
- Inner m
Here is my proposed revisions for this thread -
Add the following successful outcomes (informative messages)
1 - User account expires soon
2 - User account credential expires soon
3 - User account authorisations change soon
4 - Clock skew detected
5 - Contact administrator for unspecified reason
Hi,
> Ok, there is a misunderstanding here. What I mean is the EAP server not
> trusting the ID Management System. That might seem a bit odd, but imagine
> an EAP server trying to authenticate Kerberos against a remote KDC for
> example.
That's indeed a different meaning from what I thought it wo
Apologies for the delayed response.
>>>The question IMHO is: there are many inner EAP methods specified
>>> already, and they don't typically specify or signal most of the error
>>> conditions below to the EAP peer. The TEAP document can't impose change
>>> on all those inner methods; they are wha
Hi,
>> The question IMHO is: there are many inner EAP methods specified
>> already, and they don't typically specify or signal most of the error
>> conditions below to the EAP peer. The TEAP document can't impose change
>> on all those inner methods; they are what they are. If they tell neither
>>
Hi,
> As discussed in Berlin, to get the ball rolling here is an initial
> proposal for some inner method error conditions.
The question IMHO is: there are many inner EAP methods specified
already, and they don't typically specify or signal most of the error
conditions below to the EAP peer. The
11 matches
Mail list logo
