[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Interest in TLS authorization?
From:       Sean Shen <sshen () huawei ! com>
Date:       2009-04-08 7:35:38
Message-ID: 009d01c9b81c$9d04eab0$800c6f0a () china ! huawei ! com
[Download RAW message or body]

Hi, Nicolas,  


>On Tue, Mar 24, 2009 at 06:12:50PM -0500, Nicolas Williams wrote:
>> The only things missing then would be:
>> 
>>  - how to put SAML/whatever authorization elements into Kerberos V
>>    tickets and PKIX certificates
>> 
>>  - how to use SASL in TLS
>> 
>> The latter is a variant of "how to use the GSS-API inside TLS", and 
>> that has been controversial and has never progressed within the TLS 
>> WG.  IIRC the controversy arises from the fact that the GSS-API 
>> supports arbitrary round trips, and the same is true of SASL -- so 
>> you're likely to run into the same issue.
>> 
>> However, I think we might be able to do something about that: ride 
>> some of the SASL/GSS-API messages in TLS handshake extensions and 
>> complete the SASL/GSS-API authentication exchange after the TLS 
>> exchange completes if the SASL/GSS-API mechanism requires 
>further round-trips.
>> Such a protocol would only be usable by applications that 
>support such 
>> a protocol as that'd not be "TLS" -- but consider how many SASL apps 
>> run over TLS.
>
>Though, I should point out, this would be negotiable as it's 
>merely an optional round-trip optimization for the application 
>protocol.  It's only applicable when it is safe to defer 
>integrity protection for inital application protocol messages. 
> This extension that I'm proposing is a therefore a bit more 
>general than TLS+SASL or TLS+GSS-API.
>
>So I see several documents:
>
>1) An extension to TLS client and server hello and handshake messages
>   for carrying application protocol messages that can safely have
>   integrity protection delayed.

Does this mean to have more rounds before [ChangeCipherSpec]? In this way,
as you said, it would not be "TLS" anymore, and certainly definitions of new
messages are needed besides extensions.
If extra rounds are finished after [ChangeCipherSpec]£¬these messages will
have integrity protection, in this case, it's the application data which are
defered. Or did I misunderstand something?


Sean


[prev in list] [next in list] [prev in thread] [next in thread]