FW: Comments on the new Xauth draft

[Stephane Beaulieu <[e-mail]>]

Sorry, forgot to cc ipsec list on the reply.

-----Original Message-----
From: Stephane Beaulieu 
Sent: Wednesday, September 15, 1999 12:08 PM
To: 'Rakefet Zadik'
Subject: RE: Comments on the new Xauth draft


> Hello,
> 
>   After reading the new draft, we have a few unclear points:
> 
>   "All ISAKMP-Config messages in an extended authentication
>    transaction MUST contain the same ISAKMP-Config transaction
>    identifier.  The Message ID in the ISAKMP header follows the
>    rules defined by the ISAKMP-Config protocol."
>  
> 
>    As we understood from the thread held in ipsra, there was a
>    trend for making xauth its own exchange (separating it from
>    cfg). This draft does not reflect that understanding, furthermore
>    this draft seams to force xauth on cfg.

Yes, this was one of the proposals (proposal#2) that Joern had suggested in
his post with subject named "XAUTH is broken", posted on Jul 22 1999.  In
the same thread, I had mentioned that I was in favor of this.  However, I
received many private emails from implementors who felt that Joern's
proposal#1 from that same email was a better solution (including one email
posted to the list by Tero).  To that effect, I sent out another post named
"the next rev of XAUTH" on August 3, 1999, in which I solicited input from
the list on which of the two proposals we should proceed with.  Sadly, I
received no emails on the list itself.  However, I did receive 3 private
emails supporting Joern's first proposal (as well as Tero's earlier posting
to the list). 


> 
>    The message ID is used as a session identifier through out the
>    isakmp protocols.
>    Using the identifier as such causes inconsistency and seems
>    artificial.
> 
>    Bonding two cfg transactions for an xauth session requires a
>    state machine for the receiver, which is a contradiction to the
>    cfg protocol. Now the receiver will first have to verify according
>    to the message-id, that the message received is
>    not a reply to a cfg it sent. After the decryption, another
>    verification according to the identifier will be needed.
>             

Your ISAKMP state machine should handle the decryption process based on the
Message ID.  After that the isakmp-cfg state machine extracts the
transaction identifier and the message type to determine whether this is a
response or a new exchange.


> 
>    "If the IPSec host does not have support for the authentication
>     method requested by the edge device, then it would send back
>     a reply with empty attributes, thus failing the authentication
>     but completing the transaction. " -
>                                          
> <draft-ietf-ipsec-isakmp-xauth-05>
>  
> 
>       
> 
>    "Zero length attribute values are usually sent
>     in a Request and MUST NOT be sent in a Response."
>                              -     
> <draft-ietf-ipsec-isakmp-mode-cfg-05>
>       
     There seems to be a contradiction.
>  

Good point.  Thanks.

> 
>       
>    "Extended Authentication MAY be initiated by the edge device
>     at any time after the initial authentication exchange." - This is
>     de facto changing the life duration of the main mode after the
>     main mode is finished, why not initiate a new main mode
>     instead?
>       

Why go through the process of re-doing MM if all you want to do is refresh
user authentication?  The reason for adding this is that many authentication
servers allow you to give access to a user for a set period of time.  If the
user wishes to extend that time, then he needs to re-authenticate himself.


Thanks for your input,
Stephane.

> 
> Regards
>  
>     Keren & Rakefet
>  
>  
>