Your proposed direction for trust validation semes like a major
improvement to me.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi,
> Hi. I'm not the secdir reviewer assigned to this draft, but felt that
> this draft needed additional security review, so I decided to perform a
> secdir-like review.
>
> Overall, I think this is a much-needed specification and believe it is
> mostly ready for publication as an experimental
Stefan said:
"Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579."
[BA] Yes.
Stefan also said:
"Interesting use. I do
Hi. I'm not the secdir reviewer assigned to this draft, but felt that
this draft needed additional security review, so I decided to perform a
secdir-like review.
Overall, I think this is a much-needed specification and believe it is
mostly ready for publication as an experimental RFC. I'd say a
Hi,
comments inline.
> "Indeed. I'll update the text to that end. Note though that adding
> Error-Cause is a MAY only in 5176, so it may very well be that an
> implementation which doesn't support dynauth would still send only a
> "naked" NAK, ignoring the MAY."
>
> [BA] It's a MAY in RFC 5176 b
Hi,
>If peer communication between two devices is configured for both
>RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
>shared secret security),and where the RADIUS/UDP transport is the
>failover option if the TLS session cannot be established, a down-
>bidding
Stefan said:
"That's true. As I went through your comments below, I realised that
large parts of the texts you quoted should be moved to the
dynamic-discovery draft altogether as they are are very specific to that
draft.
I'm thinking of taking out all the snippets you mentioned below,
transfer t
Stefan said:
My working copy has the following text in Security Considerations now:
If peer communication between two devices is configured for both
RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
shared secret security),and where the RADIUS/UDP transport is the
fai
Hi again,
>>As a consequence, the selection of transports to communicate from a
>>client to a server is a manual administrative action. An automatic
>>fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
>>bidding attacks on the peer communication.
>>
>> [BA] If a fi
Hi,
comments inline.
> This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.
>
> Overall, this draft was a pleasant to read, and it is clear that a lot
> of thought as well as implementation experience has gone into it.
>
> Kudos to the authors.
Thanks :-)
> General Issues
This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.
Overall, this draft was a pleasant to read, and it is clear that a lot of
thought as well as implementation experience has gone into it.
Kudos to the authors.
General Issues
There is a considerable amount of text rel
11 matches
Mail list logo
