[kitten] Request for feedback: draft-wibrown-ldapssotoken

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Request for feedback: draft-wibrown-ldapssotoken

William Brown
Hi,

I would like to ask for feedback on the submission
draft-wibrown-ldapssotoken [0]. Section 4 deals with the SASL component
of the submission. I have been advised by Alexey Melnikov that this
seems similar to rfc7628 [1] and rfc6595 [2]. The main difference that I
see is that these rfcs rely on the external OAuth and SAML provider for
tokens. As well, they have GSSAPI integrations. The implementation I am
suggesting here is for a much simpler cryptographically based token,
that is for "small deployments" IE where no other SSO such as KRB5, SAML
or others are available. It's much more targeted around the
communication and authentication to a Directory Server: but there is no
reason it couldn't be use for simple crypto token sign on in other
applications.

Thanks for your time and advice,

[0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/
[1] https://tools.ietf.org/html/rfc7628
[2] https://tools.ietf.org/html/rfc6595

--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Request for feedback: draft-wibrown-ldapssotoken

Luke Howard
Hi William,

It would be worth mentioning in a Security Considerations section that this protocol (like all bearer tokens) is vulnerable to replay attacks.

Cheers,
Luke

> On 5 Sep 2016, at 8:35 AM, William Brown <[hidden email]> wrote:
>
> Hi,
>
> I would like to ask for feedback on the submission
> draft-wibrown-ldapssotoken [0]. Section 4 deals with the SASL component
> of the submission. I have been advised by Alexey Melnikov that this
> seems similar to rfc7628 [1] and rfc6595 [2]. The main difference that I
> see is that these rfcs rely on the external OAuth and SAML provider for
> tokens. As well, they have GSSAPI integrations. The implementation I am
> suggesting here is for a much simpler cryptographically based token,
> that is for "small deployments" IE where no other SSO such as KRB5, SAML
> or others are available. It's much more targeted around the
> communication and authentication to a Directory Server: but there is no
> reason it couldn't be use for simple crypto token sign on in other
> applications.
>
> Thanks for your time and advice,
>
> [0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/
> [1] https://tools.ietf.org/html/rfc7628
> [2] https://tools.ietf.org/html/rfc6595
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

--
www.lukehoward.com
soundcloud.com/lukehoward

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Request for feedback: draft-wibrown-ldapssotoken

William Brown
On Mon, 2016-09-05 at 11:31 +1000, Luke Howard wrote:
> Hi William,
>
> It would be worth mentioning in a Security Considerations section that this protocol (like all bearer tokens) is vulnerable to replay attacks.
>

Thank you, this is a excellent point. I have added this section and
updated the draft.

https://tools.ietf.org/html/draft-wibrown-ldapssotoken-01


--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Request for feedback: draft-wibrown-ldapssotoken

William Brown
On Tue, 2016-09-06 at 12:22 +1000, William Brown wrote:
> On Mon, 2016-09-05 at 11:31 +1000, Luke Howard wrote:
> > Hi William,
> >
> > It would be worth mentioning in a Security Considerations section that this protocol (like all bearer tokens) is vulnerable to replay attacks.
> >
>
> Thank you, this is a excellent point. I have added this section and
> updated the draft.
>

>

Hi,

As mentioned I have updated this draft. I would appreciate further
comments and review.

https://tools.ietf.org/html/draft-wibrown-ldapssotoken-01

--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (853 bytes) Download Attachment