headers
Sam Hartman | 1 Sep 2010 13:42
Picon
Favicon

Re: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11

Hi, I'm sending from my MIT address, but that's because that's where I
send my IETF mail.  In this message I want to emphasize that I'm
speaking in my role as a principal consultant at Painless Security and
my role as a Debian developer. I do not speak for the Debian Project nor
for SPI; only for myself in that role.

I've reviewed the patent disclosure. It's my understanding that we're
now supposed to consider whether our plans for naming extensions should
change based on the disclosure. (Technically it was filed against the
design document, not the actual spec, but I don't think that matters.)
We're not supposed to discuss the merits of the disclosure--especially
not evaluating whether we think the patents are valid, whether they
cover our drafts, etc.  One issue we might want to consider is whether
people who are implementing and shipping products believe they will
still want to do so and whether they believe they can get any licenses
they believe might be required.

This disclosure does not raise any concerns for me in recommending the
use of naming extensions for products where I'm doing so, nor for
shipping a product in Debian containing naming extensions.  Thinking
more broadly, I don't expect others will run into trouble with their
anticipated uses.

As such I don't believe this disclosure should change our plans for
naming extensions.

Sam Hartman
Painless Security
Permalink | Reply | 0 comments |
headers
Sam Hartman | 1 Sep 2010 21:15
Favicon

Review of draft-johannson-http-gss


This is a review of an expired draft Leif wrote a while ago.

I'm writing the review because Moonshot's implementation would like to
consume some technology like this.

First, I would like to revisit the overall approach.  At this point,
Microsoft have started using channel binding in negotiate
authentication.  As best I can tell the major advantage of this draft is
the ability to handle multi-round-trip mechanisms without assuming the
same connection is used and to do fast reauth.  Both of those are really
important benefits.

There were some issues and limitations about how the server challenge
  could be expanded without breaking IE.
Do we remember what those are?

I wonder whether it would be easier to simply provide a mechanism to
  give a context identifier and then entirely reuse the RFC 4559
  headers?

How does a client know whether a server supports channel binding?
Perhaps the server could indicate this (insecurely) in the  initial
challenge.

For Kerberos we could always include CB even if the server claims not to
support it on the grounds that they can probably deal and will have to
deal in order to play nice with microsoft.

For non-Kerberos (particularly Moonshot) I'm not sure what to do.  One
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Williams | 1 Sep 2010 22:21
Picon
Favicon

Re: [abfab] Review of draft-johannson-http-gss

On Wed, Sep 01, 2010 at 03:15:52PM -0400, Sam Hartman wrote:
> I wonder whether it would be easier to simply provide a mechanism to
>   give a context identifier and then entirely reuse the RFC 4559
>   headers?

Sounds worthwhile to me.  You could have a request header to request a
context identifier, a request header to refer to a given context by
context identifier, and a response header to indicate a server-assigned
context identifier.

> How does a client know whether a server supports channel binding?
> Perhaps the server could indicate this (insecurely) in the  initial
> challenge.

If you're using TLS and can stronly authenticate the server, then you
can live without channel binding.  Otherwise you must insist on channel
binding.

That's exactly what MSFT did, relying on the fact that the Kerberos V
GSS mechanism acceptor can ignore the initiator's channel bindings.

> For Kerberos we could always include CB even if the server claims not to
> support it on the grounds that they can probably deal and will have to
> deal in order to play nice with microsoft.

Right.

> For non-Kerberos (particularly Moonshot) I'm not sure what to do.  One
> approach would be to do something GS2-like: the client MUST include CB
> and the server MUST check them.  There is a format that includes the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 1 Sep 2010 22:40
Picon
Favicon

On the disadvantages of gs2 and Kerberos


Monday, the MIT Kerberos release meeting got into an involved
discussion of replay caches.  It was our opinion that properly
designed protocols should not require a replay cache.

I'd like to point out that it's kind of dubious whether gs2 meets this
requirement.

One obvious failure is that if GS2 is used over a channel that does
not provide confidentiality, then a replay cache is required.  Even if
the channel provides integrity, an attacker could replay the Kerberos
GSS-API exchange and gain access to the service.

We could not have fixed this in the design of GS2 without requiring
security layers.  I think this is not an issue for SCRAM because the
server needs to send a challenge.

This is also not an issue if you're using unique channel bindings.
However, the most common current use of GS2 will be for endpoint
channel bindings.

We could create a new Kerberos GSS-API mechanism to add an extra half
round trip.
(we could fix this with a special SASL mechanism, but Nico at least is off designing protocols that look a lot
like GS2 and I think I'm starting down that path myself. So, a SASL specific solution is unattractive.)

Meanwhile it's beginning to sound like we should write a GSS-API mechanism design guide. There are enough
things that are true in practice with deployed applications that are worth writing down somewhere.
Permalink | Reply | 0 comments |
headers
Sean Turner | 14 Sep 2010 21:57

Re: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00

Alexey Melnikov wrote:
> Simon Josefsson wrote:
> 
>> I have re-read the document and this version looks good to me.  Two
>> comments below.
>>
>> 1)
>>
>> I believe the document should contain a pointer to SCRAM, RFC 5802.
>> Then readers will understand that they are supposed to be implementing
>> SCRAM instead of DIGEST-MD5.  I suggest adding at the end of section 1:
>>
>>  The SCRAM mechanism [RFC 5802] has been developed to provide similar
>>  features as DIGEST-MD5 but with a better design.
>>
>> 2)
>>
>> In section 1, I would add the following bullet under 8:
>>
>>  C.  The DES cipher for the security layer is considered insecure
>>      due to its small key space.
>>
> I've just posted a new version with these 2 changes.
> 
> I haven't seen any other WGLC comments.

Somebody might complain that CRAM, 3DES, and RC4 aren't spelled out on 
first occurrence.

Maybe we should add references for the claims in 8a (I agree with your
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 20 Sep 2010 18:47
Favicon

Re: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00

Hi Sean,

Sean Turner wrote:

> Alexey Melnikov wrote:
>
>> Simon Josefsson wrote:
>>
>>> I have re-read the document and this version looks good to me.  Two
>>> comments below.
>>>
>>> 1)
>>>
>>> I believe the document should contain a pointer to SCRAM, RFC 5802.
>>> Then readers will understand that they are supposed to be implementing
>>> SCRAM instead of DIGEST-MD5.  I suggest adding at the end of section 1:
>>>
>>>  The SCRAM mechanism [RFC 5802] has been developed to provide similar
>>>  features as DIGEST-MD5 but with a better design.
>>>
>>> 2)
>>>
>>> In section 1, I would add the following bullet under 8:
>>>
>>>  C.  The DES cipher for the security layer is considered insecure
>>>      due to its small key space.
>>
>> I've just posted a new version with these 2 changes.
>>
>> I haven't seen any other WGLC comments.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Turner | 20 Sep 2010 20:05

Re: [sasl] WGLC on draft-ietf-kitten-digest-to-historic-00

Alexey Melnikov wrote:
> Hi Sean,
> 
> Sean Turner wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> Simon Josefsson wrote:
>>>
>>>> I have re-read the document and this version looks good to me.  Two
>>>> comments below.
>>>>
>>>> 1)
>>>>
>>>> I believe the document should contain a pointer to SCRAM, RFC 5802.
>>>> Then readers will understand that they are supposed to be implementing
>>>> SCRAM instead of DIGEST-MD5.  I suggest adding at the end of section 1:
>>>>
>>>>  The SCRAM mechanism [RFC 5802] has been developed to provide similar
>>>>  features as DIGEST-MD5 but with a better design.
>>>>
>>>> 2)
>>>>
>>>> In section 1, I would add the following bullet under 8:
>>>>
>>>>  C.  The DES cipher for the security layer is considered insecure
>>>>      due to its small key space.
>>>
>>> I've just posted a new version with these 2 changes.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 20 Sep 2010 21:47
Favicon

Re: WGLC on draft-ietf-kitten-digest-to-historic-00

On 8/7/10 5:30 AM, Simon Josefsson wrote:
> I have re-read the document and this version looks good to me.  Two
> comments below.
> 
> 1)
> 
> I believe the document should contain a pointer to SCRAM, RFC 5802.
> Then readers will understand that they are supposed to be implementing
> SCRAM instead of DIGEST-MD5.  I suggest adding at the end of section 1:
> 
>   The SCRAM mechanism [RFC 5802] has been developed to provide similar
>   features as DIGEST-MD5 but with a better design.

+1 -- that speaks only about the motivation behind RFC 5802, which I
think is appropriate here.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
Permalink | Reply | 0 comments |
headers
Eliot Lear | 23 Sep 2010 14:31
Picon
Favicon

seeking comments on draft-ietf-kitten-sasl-openid

 Hi everyone,

Now that this draft is posted as WG draft, might I ask for your comments
and suggestions for improvements?

Thanks,

Eliot
Permalink | Reply | 0 comments |
headers
Scott Cantor | 23 Sep 2010 17:50
Picon
Favicon

New SAML EC draft

I've submitted an update to the original SAML mechanism I proposed, as an
individual submission to the Kitten WG (in place of the original SASL), and
adding Simon as an author.

https://datatracker.ietf.org/doc/draft-cantor-ietf-kitten-saml-ec/

Simon added GS2/GSS support to the original proposal and eliminated some
redundant encoding, and I adjusted a couple of minor points, but it's mostly
unchanged otherwise.

This version does not yet have the channel bindings material that was
discussed a few weeks ago, but it *will* be added to a future draft. I have
started work on that material by producing an OASIS WD that will be the
basis of a new version of the Enhanced Client profile that this mechanism
will be based on. That new version will add support for channel bindings and
holder-of-key (as independent options), and then I'll be revising this
proposal to reference that work.

I plan to do this relatively quickly, time willing.

For reference, the Channel Bindings Extension proposal to SAML is here:

http://wiki.oasis-open.org/security/SAML2ChannelBindingExt

The new Enhanced Client proposal is in progress and I'll note it here when
it's submitted.

-- Scott
Permalink | Reply | 0 comments |

Gmane